[swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

[frogcjn at 163.com]

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 <dgregor at apple.com> 写道：
> 
> 
>> On Jul 6, 2016, at 8:34 PM, frogcjn at 163.com 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 <dgregor at apple.com> 写道：
>>> 
>>> 
>>>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution <swift-evolution at swift.org> 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 <clattner at apple.com> 写道：
>>>>> 
>>>>> 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
>>>>> swift-evolution-announce at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> 
>