Choice for choice's sake as in 100s of ways to do the same thing leads to
confusion and complexity. My suggestions are to make Swift consistent, simple,
and clear. As it is right now, the motives to keep things status quo in Swift
are the same reasons MS Windows was more difficult to use than the Mac OS:
hundreds of unintuitive ways to do the same thing added by programmers without
concern for simplicity, ease-of-use and elegance.
V. Malixi
From: Anton Zhilin <[email protected]>
To: Derrick Ho <[email protected]>
Cc: Vip Malixi <[email protected]>; Xiaodi Wu <[email protected]>;
"[email protected]" <[email protected]>
Sent: Tuesday, December 20, 2016 6:15 AM
Subject: Re: [swift-evolution] Swift Closure still inconsistent -- tuple names
need to be in curly brackets, single parameter needs to be in parentheses
2016-12-20 0:59 GMT+03:00 Derrick Ho <[email protected]>:
The core team designed swift blocks to range from concise to verbose. Which one
you use depends on your needs.
If you want to write parenthesis then by all means write parenthesis; no one is
stopping you.
I would rather keep the block syntax as it is so that everyone can choose the
style that matches their needs.
On Mon, Dec 19, 2016 at 1:52 PM Xiaodi Wu via swift-evolution
<[email protected]> wrote:
This issue about `numbers in` was raised during review of SE-0066; if I recall,
the core team considered and rejected disallowing that syntax in closures.
Since we're minimizing source-breaking changes, the issue is settled in my
view, having been proposed, commented upon, reviewed, and rejected.
Ok, I understand, you probably consider the syntax in question { param -> Int
in ... } closer to the short form { param in ... } than to the full form {
(param: Int) -> Int in ... }So when applying analogy, it makes more sense to
allow the omission as in the short form than to disallow as in the full form. I
have to agree. So, -1 to all points of the OP.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
