Does “in” really make sense semantically though? It seems to have confused
almost everywhere, and as we’ve discussed, it’s not “delimited enough”.
My recent personal proposal was the syntax:
func x, y, z { … }
– for the reasons/advantages discussed in my post stating the grammar (and
previous one).
If this can’t be effected, then I would compromise for the syntax that just
replaces `in` with `>=` in the current syntax.
I also like the proposal of changing `->` to `:` in function type specifiers,
for consistency. This also frees up another operator.
> On 23 Dec 2015, at 04:02, Jordan Rose <[email protected]> wrote:
>
> Hi, Alexander. For your most recent version, what does the syntax look like
> when there are explicit types? As far as I can tell the only change is
> substituting "in" for "=>", which means taking an existing keyword (from
> 'for' loops) and replacing it with what's currently a valid operator.
>
> We definitely thought a lot about closure syntax; what we ended up with
> (a) is concise,
> (b) has some precedent, structurally (Ruby, Smalltalk),
> (c) is easy to parse (does not require unbounded lookahead) and therefore
> easier to produce diagnostics for, and
> (d) kept the parameter list and return values looking like they do in
> declarations (when types are included)
>
> It may not be the prettiest thing in the language, but I'm not sure why any
> of your proposals are objectively better. The main thing we are missing is
> that closures do not look like standalone function declarations, but we
> decided that they're important enough that they need a lightweight syntax.
> (Compare with JavaScript for a language that did not prioritize this.)
>
> I personally love trailing closures, both here and in Ruby, so I'd put that
> down to just as much a matter of opinion as closure syntax.
>
> Best,
> Jordan
>
>
>> On Dec 22, 2015, at 19:48 , Alexander Regueiro via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> The standard map syntax is directly inspired by that of C#.
>>
>> For Swift, I’d be relatively happy with something like the following
>> (repeating what’s already been said I believe)
>>
>> map ({ x => x + 5 })
>>
>> or using trailing closure
>>
>> map { x => x + 5 }
>>
>> with the possibility of an additional single-line option:
>>
>> map ( x => x + 5 )
>>
>> (which is useful in the case of non-trailing-closure expressions).
>>
>> Of course, I’d rather remove trailing closures altogether, but I suspect
>> that won’t happen. :(
>>
>>> On 23 Dec 2015, at 03:45, Craig Cruden <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> It has probably been 6 months since I have had time to do anything
>>> interesting (JDK6 + Oracle SQL recently for contracts recently) so if I am
>>> messing up terminology or syntax - please excuse me. I messed a few things
>>> up and had to open up an old Scala project to remind me what I was doing.
>>>
>>>
>>> The standard map syntax for Scala is:
>>>
>>> a.map(x => x + 5)
>>>
>>> or using a placeholder (very limited shorthand - cannot use a placeholder
>>> twice for the same value):
>>>
>>> a.map(_ + 5)
>>>
>>> if it is a tuple then
>>>
>>> a.map(x => f(x._1, x._2))
>>>
>>> or you can pass in a function block (with pattern matching case)
>>>
>>> a.map { case (x, y) => (y, x) }
>>>
>>> there might be some mathematical reason behind the “in” keyword - but it is
>>> lost on me as well (it has been a good 30 years since University) and gets
>>> lost on me. If I had more time I might get use to it.
>>>
>>> I hope I did not mess up those examples as bad.
>>>
>>>
>>>
>>>
>>>> On 2015-12-23, at 9:52:46, Andrey Tarantsov <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>> foo.map( bar => bar.boz) // single line
>>>>
>>>> Well how important is it to use () instead of {} here?
>>>>
>>>> If you make it
>>>>
>>>> foo.map { bar => bar.boz }
>>>>
>>>> then it's like it is now, but with "in" replace by "=>".
>>>>
>>>>> foo.map { (x, y) => x * 5 + y }
>>>>
>>>> I actually like the bare version:
>>>>
>>>> foo.map { x, y => x * 5 + y }
>>>>
>>>> but not in your example (here it looks atrocious). Take this real code,
>>>> though:
>>>>
>>>>
>>>> constrain(topBlock, tableView, view) { top, tbl, sup in
>>>> top.left == sup.left + horizPadding
>>>> top.right == sup.right - horizPadding
>>>> top.top == sup.top + topPadding
>>>>
>>>> tbl.top == top.bottom + 16
>>>> tbl.bottom == sup.bottom
>>>>
>>>> tbl.left == sup.left + horizPadding - horizTableHang
>>>> tbl.right == sup.right - horizPadding + horizTableHang
>>>> }
>>>>
>>>> I think the lack of parens is beneficial in reducing the visual noise here.
>>>>
>>>>> And yes, I certainly would prefer `=>` rather than `in`.
>>>>
>>>> It seems like the community can actually agree on this.
>>>>
>>>> Does anyone know if it has any parsing problems / grammar implications
>>>> right now?
>>>>
>>>>> I think a big problem with `in` is that it’s textual, and doesn’t provide
>>>>> a clear visual separation from keywords/names at the start of the body or
>>>>> the end of the type specifier.
>>>>
>>>> Yes, agreed. “Not delimited enough”.
>>>>
>>>>> (Are the [parentheses] around `bar` in your example required? I’m
>>>>> ambivalent to them.)
>>>>
>>>> No, they are not, as shown above.
>>>>
>>>>> To be clear, I’m still not a fan of the Ruby syntax. I think it makes the
>>>>> parsing easier for a compiler but harder for a human…
>>>>
>>>> Depends on the human. To this specific human, the Ruby-style one is the
>>>> easiest to parse (and mind you, I had very limited experience with Ruby
>>>> compared to other languages, so it's not just being used to it, but rather
>>>> an honest love and preference).
>>>>
>>>> A.
>>>>
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
