Vladimir.S via swift-evolution <swift-evolution@...> 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.