On 03.07.2016 22:56, Anton Zhilin via swift-evolution wrote:
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.
If we are separating () and (()) in function call/declaration, then if
SE-0110 will be accepted, I believe first should not be allowed for
argument defined as (T)->Void.
As I understand, in case you have a code that relies on current
syntax/behavior and uses functions(not closures), you'll need a lot of
wrappers like `{_ in funcThatWasUsedAsIs()}`
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.
Got it. OK, so when reading '()->()' we should now read 'emtpy list of
parameters(0 parameters) to Void'. And only `(())->()` as '1 explicit Void
argument to Void'.
Btw, in case of 'func f(())->() {}', will call without explicit Void
parameter be allowed? I.e. `f()` or only `f(())`?
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?
Hm.. I do understand exactly this example as ambiguity *in case* we are not
require parentheses. But not after.
I.e. in case we can have `Int->Int` it is not clear if in `()->()` there is
a zero parameters or explicit `Void` parameter.
After we decided to require parentheses, `()->()` clearly means empty list
of parameters.
*But*, I feel like implicit Void parameter for function with empty list of
parameters - is an implementation detail which is currently used and
changing this will produce much more problems for current code than "Just
require parentheses on function types" as stated in the proposal in
"Proposed solution and Impact on existing code".
I really feel like I've missed something or don't understand :-) and this
is why only I is warring about this change(disallowing Void parameter for
func with empty argument list in declaration)
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
