> On 4 Apr 2016, at 18:18, Haravikk <swift-evolut...@haravikk.me> wrote:
>
>>
>> On 4 Apr 2016, at 15:49, Jeremy Pereira <jeremy.j.pere...@googlemail.com>
>> wrote:
>>
>>> 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.
>
> 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.
But the resolution would be another inconsistency i.e. a separate keyword that
is only required if the condition has a trailing closure. Furthermore, that is
an inconsistency that adds extra complexity to the language.
>
>>> 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.
I don’t view the `else` on an `if` as being some kind of second class citizen,
it’s simply one of two alternate execution paths, whereas the `else` on a
`guard` really is a second class citizen - it is even restricted what you can
put in the block i.e. it must cause the enclosing scope to be exited.
The reason why I called it a rabbit hole is because regarding the keyword in
front of a block as denoting the kind of block it is, leads us to having to
change a lot in order to make it meaningful and consistent.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
