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

[Goffredo Marocchi]

Sent from my iPhone

> On 14 Jul 2016, at 04:58, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 9 Jul 2016, at 00:53, Jon Shier <jon at jonshier.com> wrote:
>>> 
>>> While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them. 
>> 
>> I wish the core team or the author of the proposal came to this thread and engaged again with the community. 
> 
> Hi.  The core team had a long discussion about this today.  I will start a new thread to capture the discussion and update the community on the result of that.  Thank for for all of the input (even after the review period).  The core team really does care (even though everyone is insanely busy right now), we just can’t necessarily respond to every email in real time :-)
> 
> -Chris

Hi Chris,

I do appreciate you are all working hard at closing perhaps the biggest update to your new programming language in its history, I also trust you care about community input.

This was one of the issues that were key for me in this language (even though some people do not miss parameter labels in other languages) and I also felt ashamed for not being able to take active part in the review and throwing toys out of the pram now, but it is such a small yet defining and clarifying feature I had to speak out.

Thank you for listening, talking again about it, and making a plan on how to move forward.

> 
>> 
>> I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other. 
>> How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?
>> 
>> The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.
>> 
>>>> On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?
>>>> 
>>>>> On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution at 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. 
>>>>> No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.
>>>>> 
>>>>> Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160714/d8ec335b/attachment.html>