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

Tue Apr 19 09:41:31 CDT 2016

On 19.04.2016 17:11, Patrick Smith via swift-evolution wrote:
>
> I think () reads nicer than Void, and has a sort of beauty that ()
> literally looks like nothing, unlike some word. The fact that you can nest
> it is trippy in a kind of cool way.

In this case, why do we need Void at all in function type definition, and 
wider - in language ? And why do we need these ((())) as allowed parameters 
definition for functions?

Probably it is OK for me to have only () without Void, i.e.:
f: ()->()

But not all of these strange constructions like (((Void)))

Opinions?

>
> *Patrick Smith*
> *
> *
> On Apr 19 2016, at 11:28 pm, Vladimir.S via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     Although I personally have no strong opinion on this proposal yet,
>     it is clear for me that something is wrong with function type
>     sintax&Void&().
>
>     Right now we have such situation, when all the next code is OK, can be
>     compiled and run, but each fX has the same meaning:
>
>     typealias f1 = () -> ()
>     typealias f2 = () -> Void
>     typealias f3 = () -> (Void)
>     typealias f4 = () -> (())
>     typealias f5 = () -> ((((((()))))))
>
>     typealias f6 = Void -> ()
>     typealias f7 = Void -> Void
>     typealias f8 = Void -> (Void)
>     typealias f9 = Void -> (())
>     typealias f10 = Void -> ((((((()))))))
>
>     typealias f11 = (Void) -> ()
>     typealias f12 = ((((((())))))) -> Void
>     typealias f13 = (()) -> ((Void))
>     typealias f14 = ((())) -> (())
>     typealias f15 = ((Void)) -> ((((((()))))))
>
>     func f() -> Void {
>
>     }
>
>     let fv1 : f1 = f
>     let fv2 : f2 = f
>     let fv3 : f3 = f
>     let fv4 : f4 = f
>     let fv5 : f5 = f
>     let fv6 : f6 = f
>     let fv7 : f7 = f
>     let fv8 : f8 = f
>     let fv9 : f9 = f
>     let fv10 : f10 = f
>     let fv11 : f11 = f
>     let fv12 : f12 = f
>     let fv13 : f13 = f
>     let fv14 : f14 = f
>     let fv15 : f15 = f
>
>
>     Don't you think something is wrong with this?
>     Let's discuss ?
>
>     Personally I probably prefer to replace "()" with Void as a result of
>     function, and probably replace Void with "()" as parameters part. And
>     don't
>     allow empty-tuple-in-tuple at least for function type declaration + don't
>     allow Void-in-tuple. I.e. in this case we'll have only this as alowed
>     declaration:
>
>     typealias ftype = () -> Void
>
>     IMO the only clear, explicit, often used variant.
>
>
>     On 19.04.2016 10:46, Radosław Pietruszewski via swift-evolution 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 at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>     >> https://lists.swift.org/mailman/listinfo/swift-evolution
>     >
>     > _______________________________________________
>     > swift-evolution mailing list
>     > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     > https://lists.swift.org/mailman/listinfo/swift-evolution
>     >
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto: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
>