On 04.07.2016 0:36, Anton Zhilin via swift-evolution wrote:
Vladimir.S via swift-evolution <swift-evolution@...> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
