N.B. My previous observation would also rely on return being optional (at least for single-line nested functions / closures). I believe that making return statements optional at the end of a function is already being considered under another proposal.
> On 21 Dec 2015, at 21:47, Chris Lattner <[email protected]> wrote: > > >> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro <[email protected]> wrote: >> >> Hi Chris, >> >> Don’t you think the suggestion is better? I’m happy to formula it in terms >> of an E(BNF) grammar if you like. Is this published/available anywhere, for >> the current version of Swift? > > My personal opinion is “no”, because it will look very weird in trailing > closure, in the argument lists for function calls, etc. > > Further, it would not permit dropping ()’s on closure arguments, you wouldn’t > be able to write this: > > foo({ lhs, rhs in … }) > > because the comma would be exposed out to the function call. > > The grammar is described in the reference section of TSPL: > https://swift.org/documentation/ > > In addition to proposing EBNF, please consider the existing grammar so that > the new proposal isn’t completely ambiguous. What you are proposing would be > an extremely tricky thing to do. > > -Chris > > >> >> Thanks. >> >>> On 21 Dec 2015, at 19:22, Chris Lattner <[email protected]> wrote: >>> >>>> >>>> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> Does anyone not like the current syntax for this? >>>> >>>> I would propose changing it from: >>>> >>>> { (param_list) -> return_type in … } >>>> >>>> to something cleaner like: >>>> >>>> (param_list) -> return_type => { … } >>>> >>>> where I’m not so bothered about the `=>` separator (could be `:`, `,`, or >>>> indeed `in`). >>>> >>>> The braces being around the type specifier as well as function body rather >>>> bothers me. Surely it would be more consistent just to have the braces >>>> around the function body, and then the type specifier preceding this? >>> >>> Hi Alexander, >>> >>> We’re open in principle to replacing closure syntax with something better, >>> but A) it needs to be actually better, and B) it needs to fit with the >>> swift grammar. If you’re interested in pushing forward in this area, >>> please familiarize yourself with the structure of the grammar and propose >>> what you’re thinking in terms of a diff to it. Thanks, >>> >>> -Chris >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
