I personally find that { foo(a: $0, c: $1) } is an already simple enough way to
solve that problem.
Félix
> Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution
> <[email protected]> a écrit :
>
> l'd like the way of Python to handle the function signature.Assign lost other
> possibility of that function:
>
> foo(b:c:)
> foo(a:c:)
> foo(a:b:)
> foo(a:)
> foo(b:)
> foo(c:)
> foo()
>
> very weird.
>
>
>
>> 在 2016年7月7日，11:36，Douglas Gregor <[email protected]> 写道：
>>
>>
>>> On Jul 6, 2016, at 8:34 PM, [email protected] wrote:
>>>
>>> so how you call bar and get default values for a, b, c?
>>
>> You don’t.
>>
>>> why lost default value for that function? it is wired.
>>
>> Default values aren’t part of a function type. While it is possible to come
>> up with such designs, there is little precedent for them and doing so either
>> drastically limits what kinds of default arguments can be expressed or
>> causes values of function type to become large (so they can encode the
>> computation of the default values).
>>
>> - Doug
>>
>>>
>>>> 在 2016年7月7日，11:29，Douglas Gregor <[email protected]> 写道：
>>>>
>>>>
>>>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution
>>>>> <[email protected]> wrote:
>>>>>
>>>>> Don't agree with this one.
>>>>>
>>>>> func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
>>>>> print(a, b, c)
>>>>> }
>>>>>
>>>>> foo(a: 1, c: 3)
>>>>>
>>>>> let bar = foo
>>>>>
>>>>> bar(1, 3) will different than foo(a: 1, c: 3)
>>>>
>>>> bar(1, 3) will result in an error, because “bar” is of type
>>>>
>>>> (Int, Int, Int) -> Void
>>>>
>>>> Default arguments are associated with function declarations, not function
>>>> types.
>>>>
>>>> - Doug
>>>>
>>>>
>>>>>
>>>>>> 在 2016年7月7日，11:06，Chris Lattner <[email protected]> 写道：
>>>>>>
>>>>>> Proposal Link:
>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>>>>>>
>>>>>> The review of "SE-0111: Remove type system significance of function
>>>>>> argument labels " ran from June 30 ... July 4, 2016. The proposal has
>>>>>> been *accepted*:
>>>>>>
>>>>>> The community and core team agree that this proposal will lead to a
>>>>>> simplification and clarification of the type system, as well as a more
>>>>>> clear user model for parameter labels. In response to community
>>>>>> feedback, the core team is accepting the proposal with a revision to
>>>>>> allow “purely cosmetic” parameter labels in closure types for
>>>>>> documentation (as outlined in the alternatives section). The core team
>>>>>> also wants to clarify that a call to a value of closure type would not
>>>>>> allow use of any parameter labels, some interpretations thought that
>>>>>> “arbitrary” parameter labels could be used.
>>>>>>
>>>>>> Thank you to Austin Zheng for driving this discussion forward! I filed
>>>>>> SR-2009 to track implementation work on this.
>>>>>>
>>>>>> -Chris Lattner
>>>>>> Review Manager
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution-announce mailing list
>>>>>> [email protected]
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
