Completely agree with Radek. I avoid unnecessary punctuation whenever possible, which increases legibility IMHO; so this pernickety proposal makes me sad : (
> On 19 Apr 2016, at 08:46, Radosław Pietruszewski via swift-evolution > <swift-evolution@swift.org> wrote: > > Noooooo :( > > I understand and appreciate the rationale, uniformity between declaration and > use site being a good thing, but IMHO the proposal just brings unnecessary > noise, far outweighing the small benefit of having the symmetry. > > 1. What I’m worried the most is the “parentheses blindness”. In higher-order > functions, or just when I take a simple callback closure, there are just a > lot of parentheses (add to that generics, and there’s a lot of angled > brackets too). And it just becomes hard to instantly decipher. To me, `func > blah(f: Int -> Float) -> String` is easier to read that `func blah(f: (Int) > -> Float) -> String`. Or just notice how noisy `(f: () -> ())` is. This is > why I like the convention of using `Void` for void-returning functions. > There’s less noise in `(f: () -> Void)`, and even better in `(f: Int -> > Void)`. I don’t have to mentally match parentheses, because whenever > possible, there’s just one set of parens around the main function > declaration. When punctuation like parentheses is used sparingly, it carries > a lot of weight. Requiring parentheses around T in T -> U doesn’t seem to > have a significant reason aside from style/taste. > > 2. I’m not convinced at all that `(Foo) -> Bar` is immediately more obvious > to people. I don’t have data to back it up, but my intuition is that `Foo -> > Bar` is simple and understandable. “A function from Foo to Bar”, I’m > thinking. I don’t have to mentally parse the vacuous parentheses, just to > conclude that there’s, in fact, just one parameter. And when there is more > than one parameter, the parentheses in `(Foo, Bar) -> Baz` instantly carry > more weight. > > 3. Swift has been really good at removing unnecessary punctuation. > Parentheses in if statements, semicolons, shortcut forms of closures, etc. > This is a good thing. As I said before, using punctuation only when it > matters makes it stand out, and in places where it doesn’t, by removing it > we’re increasing the signal-to-noise ratio. To me, parentheses in `(Foo) -> > Bar` don’t matter. I can see why one could argue for them, or prefer them, > but it seems like a merely stylistic choice. Let’s keep them where it > matters, and leave this to personal preference. > > Best, > — Radek > >> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> We currently accept function type syntax without parentheses, like: >> >> Int -> Float >> String -> () >> >> etc. The original rationale aligned with the fact that we wanted to treat >> all functions as taking a single parameter (which was often of tuple type) >> and producing a tuple value (which was sometimes a tuple, in the case of >> void and multiple return values). However, we’ve long since moved on from >> that early design point: there are a number of things that you can only do >> in a parameter list now (varargs, default args, etc), implicit tuple splat >> has been removed, and the compiler has long ago stopped modeling function >> parameters this way. Beyond that, it eliminates one potential style war. >> >> Given all this, I think it makes sense to go for syntactic uniformity >> between parameter list and function types, and just require parenthesis on >> the argument list. The types above can be trivially written as: >> >> (Int) -> Float >> (String) -> () >> >> Thoughts? >> >> -Chris >> _______________________________________________ >> 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
