> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Although I use trailing closures a lot less now, I think I’m a +1 anyway for 
> consistency’s sake.
> 
> I actually really like the idea of having trailing keywords in loops and if 
> statements, these needn’t be required (except where a trailing closure is 
> used) but for example it means I could do a fully natural language loop like:
> 
>       for eachValue in theValues do { … }

This is actually kind of bizarre. Here we are trying to invent new syntax so 
that the trailing closure can be used in if/while conditions and for sequences. 
However, there is already a perfectly good syntax for putting closures in these 
positions: put the closure in the parentheses of the function call. Are people 
really so desperate to use trailing closures everywhere that we have to add new 
keywords to the language? I don’t think they are.

> 
> I like the consistency of every block having a kind of type (do, else, defer, 
> catch etc.). 

That is a rabbit hole down which you probably shouldn't go. If we go down the 
route of blocks having a “type”, the current situation in Swift becomes 
somewhat inconsistent. I would argue that the `else` block on a `guard` is of a 
different type to the `else` block on an `if`. If anything, the `else` block of 
an `if` is closer to the `then` block. Also, would you allow the `do` block in 
a `for` or `while` to have a `catch` block following it? If not, then these 
blocks are different to the  existing bare `do` block. 

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to