This is very similar to my proposal. We were later suggesting the use of `=>` in place of `in`, but formerly I suggested essentially what you did here, but with `func` or `\` in place of `>=` to signify the start of a closure expression.
> On 23 Dec 2015, at 10:21, Brent Royal-Gordon <br...@architechies.com> wrote: > > 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