-1 The parenthesis don't add anything, in my opinion. I could live with the change, I simply don't see much benefit.
On Tue, Apr 19, 2016 at 8:45 AM, Matthew Johnson via swift-evolution < [email protected]> wrote: > > > Sent from my iPad > > > On Apr 19, 2016, at 2:46 AM, Radosław Pietruszewski via swift-evolution < > [email protected]> 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. > > Thanks for posting this Radek. I agree with everything you said. > > > > > Best, > > — Radek > > > >> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution < > [email protected]> 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 > >> [email protected] > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
