[swift-evolution] Lambda function syntax

[James Campbell]

Why not just do ?

On Wed, Dec 23, 2015 at 1:02 PM, Daniel Valls Estella via swift-evolution <
swift-evolution at swift.org> wrote:

> I think => may be confusing in many of shown cases. Its a cause/efect
> symbol and can be also and operator.
>
> I put again the idea of with for the newcomers:
>
> with (  *parameters* ) -> *return_type* {
>     *statements*
> }
>
>
> sorted = names.sort( *with*(s1, s2){ s1 > s2 } )
>
> sorted = names.sort( *with*{ $0 > $1 } )
>
>
> sorted = names.sort()  *with* { $0 > $1 }
>
> reversed = names.sort *with*(s1,s2){
>
> //bla bla code
> return resultVar
> }
>
> reversed = names.sort *with* { $0 > $1 }
>
>
> But thinking about it, what we are really always doing with clousures is
> solving a quicky tiny delegation pattern. Maybe we could name it what it
> is. Too long word, but just to brainstorm.
>
> delegating (  *parameters* ) -> *return_type* {
>     *statements*
> }
>
>
> sorted = names.sort( *delegating*(s1, s2){ s1 > s2 } )
>
> sorted = names.sort( *delegating*{ $0 > $1 } )
>
>
> sorted = names.sort()  *delegating*{ $0 > $1 }
>
> reversed = names.sort *delegating*(s1,s2){
>
> //bla bla code
> return resultVar
> }
>
> reversed = names.sort *delegating*{ $0 > $1 }
>
>
>
> :)
>
> El 23 des 2015, a les 12:49, Pierre Monod-Broca via swift-evolution <
> swift-evolution at swift.org> va escriure:
>
> I like that the closure parameters are inside the closure, to me it makes
> as much sense as outside. They're the input, so as much in as out.
>
> I have nothing against `in`, but I wouldn't be against a sensible
> replacement.
> I like `=>`, but I'm concerned it might be confused with `->` by beginners
> in swift.
>
> --
> Pierre
>
> Le 23 déc. 2015 à 11:21, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> I have to admit I haven't read the entire thread, so maybe I missed
> discussion of this.
>
> I, too, don't like the `params in code` syntax. After a year and a half
> with Swift, I now remember it, but it still reads funny, and I see new
> developers struggle with it frequently. I've also used Ruby quite a bit,
> but I really don't like the `||` syntax there either.
>
> What I would do is pull the parameters/type signature out of the braces
> and put a symbol in front of them. For example:
>
> let names = people.map => person { person.name }
>
> database.saveRecord(record) => record, error {
> if let record = record {
> completionHandler(true)
> }
> else {
> handleError(error!)
> }
> }
>
> `=>` is used here merely because it's been discussed upthread; I actually
> think it's a little too heavy for this role, but I don't have a great
> replacement immediately at hand.
>
> A no-parameters closure would not require a `=>`; a bare block would still
> do there. I suppose the capture list would still go before the parameters,
> but after the `=>`. Other closure features remain the same—you can still
> use the `$N` implicit parameters, and you can still use `->` to specify a
> return value, `()` to surround the parameters, `:` to specify exact types,
> etc.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/d3b2c281/attachment.html>