[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[T.J. Usiyan]

-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 <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> > On Apr 19, 2016, at 2:46 AM, Radosław Pietruszewski via swift-evolution <
> swift-evolution at 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.
>
> 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 <
> swift-evolution at 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 at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160419/355d4641/attachment.html>