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

[Anton Zhilin]

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

> On 03.07.2016 22:56, Anton Zhilin via swift-evolution wrote:
> > 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()}`

Right.
By "luck" I mean if determining closure argument count
from context will finally work as expected. In this case,
closure in the first version will implicitly take 1 parameter,
because 'async' requires it to do so.

Anyway, we will have to write at least {funcThatWasUsedAsIs()}.

> Btw, in case of 'func f(())->() {}', will call without explicit Void 
> parameter be allowed? I.e. `f()` or only `f(())`?

Only `f(())`. By the way, you need a label at function declaration.

> *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".

Right, there is some impact on existing code that was omitted
in the proposal. And it wasn't considered during review. Awkward.

We could add implicit convertion
() -> T  to  (U) -> T
I feel that is one constructive way out.