[swift-evolution] [Pre-proposal] Fix function type grammar

[Anton Zhilin]

Vladimir.S via swift-evolution <swift-evolution at ...> writes:

> OK.. could you clarify, so, after the changes, we will not be able to 
pass 
> `func f()->()` as parameter where parameter of type `typealias 
MyFunc<T> = 
> (T) -> Void` is expected, right?

Right. But the change is not as dramatic as you suppose.
Consider this example:

func async<T>(with: T, do: (T) -> Void)

async(with: (), do: { ... })

With this change, it will become:

async(with: (), do: { _ in ... })

This is what will change in practise. With enough luck, even the first 
version will typecheck.

> And what about the result type? What does `-> ()` now will mean? still 
> "implicitly returns Void" or "returns nothing"? Or in case you want to 
> return Void you'll need to write `-> Void` ?

Parameter part will become a list of types; result will still be a 
single type, including unit type and closure types. So no changes on 
this part.

> And most likely I'm missing something, but I don't see where SE-0066 
> mentions this aspect (disallow implicit Void argument in function 
which is 
> defined as '()->()'), as I understand it is only about requirement of 
> parentheses in declaration like Int->Int. Could you point me please?

Citation:

Allowing this sugar introduces ambiguities in the language that require 
special rules to disambiguate. For example:

() -> Int // Takes zero arguments, or one zero-argument parameter?

This syntactic sugar reduces consistency with other parts of the 
language, since declarations always require parentheses, and calls 
requires parentheses as well.

Finally, while it is straight-forward to remove this in Swift 3 (given 
the other migration that will be necessary to move Swift 2 code to Swift 
3), removing this after Swift 3 will be much harder since we won't want 
to break code then. It is now or never.