Why not just do ? On Wed, Dec 23, 2015 at 1:02 PM, Daniel Valls Estella via swift-evolution < swift-evolution@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@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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Wizard ja...@supmenow.com +44 7523 279 698
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution