Just to add my point of view as language user. I don’t know so much about
compilers and neither have many familiarity with language grammars. I like to
learn, and this list helps.
I think clousures are strangely written and break some coherence. I agree with
Alexander on that.
But I don’t like the proposed solution.
In the other side, I think trailing closures are a really a great feature, I
like a lot.
But I feel it’s a bit confusing in some way, as Alexander pointed. As if it was
the body definition of the called function.
To throw an idea, the with keyword:
with ( parameters ) -> return_type {
statements
}
sorted = names.sort( with(s1: String, s2: String) -> Bool {
return s1 > s2
})
sorted = names.sort( with(s1, s2){ return s1 > s2 } )
reversed = names.sort( with(s1, s2){ s1 > s2 } )
reversed = names.sort( { $0 > $1 } )
OR? reversed = names.sort( with{ $0 > $1 } )
reversed = names.sort(>)
OR? reversed = names.sort(with >)
reversed = names.sort() with { $0 > $1 } // I think clarifies it is an input
to exeute not a definition
reversed = names.sort with { $0 > $1 } // I think clarifies it is an input to
exeute not a definition
Thanks!
Daniel
Daniel Valls Estella · tel. 659.910.830 · [email protected]
> El 22 des 2015, a les 7:57, Thorsten Seitz via swift-evolution
> <[email protected]> va escriure:
>
> Well, I'm actually happy with the current closure syntax as it allows very
> succinct simple cases and trailing closures as Chris has already pointed out.
>
>> Am 21.12.2015 um 23:44 schrieb Alexander Regueiro via swift-evolution
>> <[email protected]>:
>>
>> Okay, I assume you are aware this essentially the same syntax as used in
>> languages like C# and Python, yes? I’m not sure there are any problems in
>> those languages with it.
>>
>>> If you dig through (very early) history you’ll see that we had this. There
>>> are a couple of problems with it:
>>>
>>> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of
>>> simple map and filter closures.
>>
>> Not really. The above example would just be `X.sort func { $1 < $0 }” or
>> "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have
>> all operators implicitly
>
> Having "func" or the backslash crammed in there is really ugly and unreadable
> IMHO.
>
> And in Haskell you don't have braces for the body to begin with and you would
> have to enclose the closure in parenthesis if it is part of an expression
> like your examples so in effect it would look quite similar, i.e. having the
> parameters within the parenthesis (sure, the semantics are different, but I
> made argument just to demonstrate that what looks good in one syntactic
> environment might not look good in another).
>
>>> 2) It reads really weird in trailing closure cases.
>>
>> Honestly, I strongly dislike trailing closures. I don’t think they add much,
>> and moreover they use a confusing syntax that make the whole function call
>> look superficially like a function declaration (or indeed the whole thing
>> being a closure).
>
> Trailing closures are a great feature IMHO because they make the code much
> more readable by allowing constructs to look similar to control flow
> statements.
> This allows creating very readable DSLs.
>
>
>>> Lets step back: What problems are you trying to solve with the current
>>> closure syntax?
>>
>> Readability, mainly. I think this is a big improvement.
>
> Well, I think it's the opposite for the simple cases and for trailing
> closures.
>
>
>> Then there’s similarity with other languages, which is minor, but nice. I
>> don’t know any language that uses a syntax like the current one of Swift.
>
> Smalltalk and Ruby immediately come to mind and I'm sure there are others.
>
> Scala has a trailing closure syntax which is similar to Swift's syntax as
> well.
>
> -Thorsten
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
