I’m against everything here. It’s universally worse, in my view. > On 23 Dec 2015, at 10:05, James Campbell <[email protected]> wrote: > > I don't think either are that nice, we could do a ruby thing and use "do". > The do expresses that we are passing in a block :) and the arguments are on > the outside of the closure which matches iit elsewhere: > > heyThere() do |hi, there| > { > > } > > we could allow anon functions like so: > > heyThere((hi, there){ > }) > > But then its inconsistent, so I don't mind what swift does now :) as its > consistent whether its a closure block or a argument we are passing in. > > Regarding the "=>" vs "in" debate, they are both obtuse to me. In some-ways > "in" is better as it reads to me as "the arguments in this closure" so I > would much prefer "in". I know this is subjective but that's just my two > cents ;) > > On Wed, Dec 23, 2015 at 9:42 AM, Tino Heth via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> love trailing closures > I wouldn't go that far and just say "})" looks ugly — but that has the same > implications ;-) > With parameters, trailing closures loose a lot of their appeal, and an > alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that bad > for trailing closure either. > > The only obvious downside is the "$0" shortcut would be confusing with > "func() {" (but not so much with "func {"…). > Speaking of "$0", you could argue why it is allowed in closures and not in > methods… but I'm in some discord with $0 anyways: > It is really nice for small constructs, but drawing the line when to > discourage their use is tough (at least to tough for the compiler to enforce > a rule). > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > > -- > Wizard > [email protected] <mailto:[email protected]> > +44 7523 279 698
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
