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

[Vladimir.S]

On 04.07.2016 0:36, Anton Zhilin via swift-evolution wrote:
> 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()}.

I see. Yes, IMO in this case `{funcThatWasUsedAsIs()}` will be much better.

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

Oh, yes, of course: 'func f(_:())->() {}'. OK.

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

Probably because some(many?) people (like me) did not understand that this 
proposal is much bigger than "Just require parentheses on function types", 
because IMHO the major idea of this proposal was disallow `Int->Int` syntax 
but not to disallow void parameter for zero parameter functions.

I hope community will provide opinions regarding this issue and about the 
decision regarding the void parameter to argument-less functions, and if 
that decision is really expected and was clearly mentioned in the proposal.

Personally I think we need to implement the proposal in all areas except 
this one and raise new proposal to make all things clear regarding 
argument-less functions.

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

Could you clarify the suggestion with some details?
Do you suggest, that we can pass ()->T where (U)->T is required?


>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>