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

[Vladimir.S]

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> 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
>