> On 4 Apr 2016, at 15:49, Jeremy Pereira <[email protected]> 
> wrote:
> 
>> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution 
>> <[email protected]> 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.

While I kind of agree (and personally prefer the use of parenthesis in most 
places anyway) it’s an inconsistency to be unable to use them I think. While 
It’s understandable from a parsing/ambiguity perspective, it’s not really 
intuitive.

>> 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. 

Actually that’s not quite what I meant by “type”; while there is a case to be 
made for unifying these more (else and catch on loops for example) I just meant 
more along the lines that “do” would always group the main branch, “else” 
indicates an alternative path if a condition isn’t met and so-on. For the short 
term however this would just be a case of allowing do on the end to eliminate 
ambiguity and thus allow trailing closures, but in the long term it could be 
explored further.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to