It feels so odd especially because of the added emphasis by the core team for
argument labels for Swift 3 only to have this passed.
What is the pro of not having argument labels in callbacks or functions stored
in properties, how does this make for good readability or consistency with
instance methods once they are mixed and matched?
> completion(true, false,...) + debugging
This kind of methods always was a pain in other languages and a source of
annoyance when taking over or reviewing other people's code :(.
If argument labels are not even mandatory in the closure declaration when
passed as a method, how is it clear at all what parameters you have to pass and
in which order at call site?
Sent from my iPhone
> On 8 Jul 2016, at 01:49, Diego Sánchez via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Aw. It's really bad that labels are gone for closures at the call site 😢.
> IMHO, the same principles that encourage the use of labels for "normal"
> function calls should prevail here.
>
> I hope I won't come across to many completion(true, false,...) + debugging if
> someone changes the order of the parameters in some branch and another one is
> merged adding a new call to the closure type with the old order.
>
> Looks to me that the problem solved may cause more trouble than what was
> fixed :/
>
> Sorry for failing at giving my feedback during the review period :(
>
> Sent from my iPhone
>
>> On 8 Jul 2016, at 12:15 am, Douglas Gregor via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>> On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>> I would also be interested in a clarification on this point from Chris or
>>> someone else from the core team.
>>>
>>> The accepted proposal states that labels are illegal in function types
>>> (that is also what I was arguing for towards the end of the review
>>> discussion) but at the same time Cris mentions that cosmetic labels are
>>> allowed in closure types (which for me is synonymous with function types).
>>> So which one is it and how does this change affect closure parameters?
>>
>> The core team’s intent is that one can add cosmetic labels to function
>> types, but that those labels are not (cannot be) used at the call site, e.g.,
>>
>> func foo(fn: (success: Bool) -> Void) {
>> fn(true) // note: no ‘success:’ argument label
>> }
>>
>> func bar(something: Bool) { }
>>
>> foo(bar) // okay: labels not considered
>>
>> The proposal should be updated accordingly so it’s clear for future readers.
>> PR welcome ;)
>>
>> - Doug
>>
>>>
>>> Best,
>>>
>>> Taras
>>>
>>>
>>>> On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> Hey Charlie,
>>>>
>>>> The change you reference and this must work together, I have a hard time
>>>> accepting that we will have a Swift 3 with this change in and no other
>>>> change that balances it.
>>>>
>>>> If this
>>>>
>>>> function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {
>>>>
>>>> [...]
>>>>
>>>> callback(20,40, true)
>>>>
>>>> }
>>>>
>>>> is the style we have to use with callbacks from now on, it will be a major
>>>> regression I would advise a proposal to stop right now.
>>>> The closure passed around and arriving as a callback there gives me NO
>>>> clue how to send data to it. How is that for local reasoning?
>>>> This makes me believe/hope that I am getting it all wrong, so please
>>>> correct me here :D.
>>>>
>>>> If it is not true, then I am blowing things out of proportion and I
>>>> apologise for this to everyone on the list.
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On 7 Jul 2016, at 08:41, Charlie Monroe <char...@charliemonroe.net> wrote:
>>>>>
>>>>> There was a fair proposal by Brent
>>>>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of
>>>>> adding the labels to the name of the variable rather than adding it to
>>>>> the type. And I agree with that since it simplifies the type system.
>>>>>
>>>>> Unfortunately, since Swift 3 is making all the code-breaking changed and
>>>>> Brent's counterproposal is additive, it leaves at least a year-long
>>>>> period of not having the parameter labels in closures.
>>>>>
>>>>> I agree with the change, I don't agree with the timing where it doesn't
>>>>> have a replacement yet.
>>>>>
>>>>>> On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>> This feels like making the language a lot worse. Lots of time was
>>>>>> recently spent bikeshedding methods names and argument labels and this
>>>>>> proposal bans labels use in some cases and encourage people not to use
>>>>>> them in others.
>>>>>>
>>>>>>> On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>> func needsCallback(callback: (a: Int, b: Int) -> Void) {
>>>>>>> callback(a: 1,b: 2)
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> func needsCallback(callback: (Int, Int) -> Void) {
>>>>>>> callback(1, 2)
>>>>>>> }
>>>>>>>
>>>>>>> Is the first one will be forbidden?
>>>>>>> So you'd like to keep the second one?
>>>>>>
>>>>>> I do not understand why someone would want the second example. A great
>>>>>> point of both Objective-C and Swift was enforcing parameter labels use
>>>>>> to make the code more readable.
>>>>>>
>>>>>> What if that callback were to need width and height? How is that clear
>>>>>> which parameter I need to pass in which order?
>>>>>>
>>>>>> Considering Swift 3 is our last big chance to break code and fixing the
>>>>>> effects of this proposal would break quite a bit of code again... this
>>>>>> is a choice it would impact the language for a long time.
>>>>>>
>>>>>>
>>>>>>>> 在 2016年7月7日，11:06，Chris Lattner via swift-evolution
>>>>>>>> <swift-evolution@swift.org> 写道：
>>>>>>>>
>>>>>>>> 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 mailing list
>>>>>>>> swift-evolution@swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution@swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution@swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
