It would not prevent curly brackets for single-line cases…. just the difference between a map function call map() vs infix with scope.
> On 2015-12-23, at 9:48:24, Alexander Regueiro <[email protected]> wrote: > > Why not curly braces for single-line and multi-line cases? About the brackets > around multiple parameters: like I said before, no strong opinion either way. > >> On 23 Dec 2015, at 02:46, Craig Cruden <[email protected]> wrote: >> >> I am joining this discussion a little late - so I would not be surprised if >> discussed earlier. >> >> but: >> >> My preference would be: >> >> foo.map( bar => bar.boz) // single line >> >> or >> >> foo.map { bar => >> …. >> } >> >> if more than one line >> >> if there are multiple values then: >> >> foo.map { (x, y) => x * 5 + y } >> >> >> >> >>> On 2015-12-23, at 9:39:03, Andrey Tarantsov via swift-evolution >>> <[email protected]> wrote: >>> >>> One thing I'm really bothered by in C# and ES6 are no-argument methods: >>> >>> () => { foo() } // GROSS >>> >>> The syntax of C# isn't so bad, though, when there's no return type: >>> >>> foo.map((bar) => bar.boz) >>> >>> but those double-parens bother me and my eyes a bit, so this definitely >>> looks better: >>> >>> foo.map { (bar) => bar.boz } >>> >>> I think I'd even prefer that to: >>> >>> foo.map { (bar) in bar.boz } >>> >>> >>> What if we just agreed to replace "in" with "=>"? Would that be an >>> improvement in your eyes? I could stand behind that proposal. >>> >>> (btw Chris & team — THANK YOU for the Ruby-style trailing closure syntax, >>> it was such a treat to see it last summer!) >>> >>> A. >>> >>> >>>> On Dec 23, 2015, at 8:33 AM, Alexander Regueiro <[email protected]> wrote: >>>> >>>> This was my first proposal, and was changed my second, but this syntax is >>>> inspired by C#, where a lambda expression is of one of the following forms: >>>> >>>> (Type1 param1, …) => foo // single-statement expression >>>> (Type1 param1, …) => { …; return foo; } // multi-statement expression >>>> >>>> Haskell also uses syntax closer to this than to Swift, not to mention >>>> ML/F#. >>>> >>>>> On 23 Dec 2015, at 02:30, Andrey Tarantsov <[email protected]> wrote: >>>>> >>>>> So I believe the opinion of the core team and the community would be >>>>> generally in opposition to the style you want. I understand your >>>>> arguments, but somehow they are against the entire experience of me (and, >>>>> presumably, others) as developers. >>>>> >>>>> To continue our friendly banter, though, do you mind sharing your >>>>> background? When I read this, I wasn't sure if you're serious or trolling: >>>>> >>>>>> I would propose changing it from: >>>>>> >>>>>> { (param_list) -> return_type in … } >>>>>> >>>>>> to something cleaner like: >>>>>> >>>>>> (param_list) -> return_type => { … } >>>>> >>>>> I wonder if doing something like Haskel a lot makes you more used to that >>>>> sort of arrow constructs? >>>>> >>>>> This is written in good faith; I hope I used the right tone to indicate >>>>> that. >>>>> >>>>> A. >>>>> >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
