[swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

[Vip Malixi]

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 <antonyzhilin at gmail.com>
 To: Derrick Ho <wh1pch81n at gmail.com> 
Cc: Vip Malixi <vip_m at yahoo.com>; Xiaodi Wu <xiaodi.wu at gmail.com>; "swift-evolution at swift.org" <swift-evolution at swift.org>
 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 <wh1pch81n at gmail.com>:
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 <swift-evolution at swift.org> 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.​

   
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161220/731408df/attachment.html>