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

Sat Jul 9 13:03:42 CDT 2016

Thank you Austin.

You asked for engagement with the community, I have provided as such. I did
> not desire to do so originally,

Appreciated, I only felt the assumption of "not participating in the
original review" == "people not worth talking to" felt a bit patronising,
the way it was coming off, as it assumed quite a bit of explicit ill
intent.

You use labels when invoking the method using its original name, because
> the labels are (almost always) prepositional phases that modify, and as
> such only make sense in the context of, the original method name.

The concern is using the labels when calling a method passed to a function
where it is currently explicitly banned. More than reversing the proposal,
unless it is the only way to do so, it is finding a way to mandate the
argument labels when calling a callback method (or a method saved in a
closure type parameter which is essentially the same thing). I do not want
to go back to a era of passing two or more arguments to a function without
argument labels unless the language never had argument labels to begin with
or held them in high regards.

I will consider the rest of your points and re-read the original list
before posting in this thread again (unless somebody asks me a question :)).

On Sat, Jul 9, 2016 at 6:58 PM, Austin Zheng <austinzheng at gmail.com> wrote:

> Apologies, I meant to send this out to the list. If you wish to rebut my
> points, you are welcome to cc the list with my blessing.
>
> Best,
> Austin
>
>
> On Jul 9, 2016, at 10:55 AM, Goffredo Marocchi <panajev at gmail.com> wrote:
>
> You asked for engagement with the community, I have provided as such.
>
>
> Thank you.
>
> On Sat, Jul 9, 2016 at 6:43 PM, Austin Zheng <austinzheng at gmail.com>
> wrote:
>
>>
>> On Jul 9, 2016, at 10:26 AM, Goffredo Marocchi <panajev at gmail.com> wrote:
>>
>> Sorry for not participating, I do blame myself from missing how key that
>> change was. I can blame a very busy period, but that does not really matter.
>>
>> I do think your attitude on this matter is a bit toxic and presumptuous
>> ("people who couldn't be bothered to give feedback") though as if you are
>> looking down on other members of the list for this unforgivable sin.
>> Maybe it is not a matter of giving a damn about helping out the review of
>> the proposal although I can understand the frustration of people
>> disagreeing after the review period, but you should take it less personally
>> as it comes just out of care for the language and ideals even if it may be
>> as flawed as it can be.
>>
>>
>> You asked for engagement with the community, I have provided as such. I
>> did not desire to do so originally, as my participation in the review
>> thread degenerated into me making the same points again and again to
>> different people, and my participation in this thread would have become
>> more of the same, but here I am.
>>
>> As for your other points, they are addressed abundantly in the original
>> thread, both by me and by multiple other people. Please in particular note
>> the delineation between argument labels used to identify the semantic
>> meaning of an argument, and argument labels as prepositional phrases which
>> modify the primary function name.
>>
>>
>>> 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?
>>>
>>>
>>> If you really want to promote local reasoning, write short methods and
>>> look at the function signature, where you can stick labels. Or use the type
>>> system or typealiases.
>>>
>>> A better solution might be the compound function names that came up
>>> during both the review thread and this thread (e.g. let foo(with:for:) :
>>> (Int, Int) -> Bool = blah). Those were going to be added to the original
>>> proposal during private review, but were nixed. If someone feels strongly
>>> enough about the issue, they should submit a PR for a proposal amendment or
>>> a follow-up proposal.
>>>
>>>
>>  So, you think having code with multiple parameters passed with
>> obligatory labels mixed with methods where multiple parameters may/have to
>> be passed without argument labels and where the definition of the function
>> and its argument may well be outside of the method body improving clarity
>> and local reasoning or just easy to hand wave away with a "write shorter
>> methods" ?
>>
>>
>> Yes I do.
>>
>> You use labels when invoking the method using its original name, because
>> the labels are (almost always) prepositional phases that modify, and as
>> such only make sense in the context of, the original method name.
>>
>> You don't use labels when you erase the original context under which the
>> argument labels were defined by assigning a value of function type to a
>> variable whose name may or may not have any relation to the original method
>> name (again, this was discussed thoroughly in the review thread).
>>
>> You can still use labels when defining your closure type arguments to a
>> function or method. Hence, "shorter methods", where the definition of the
>> relevant closure-type parameter is always a glance away.
>>
>> I don't know why you are grousing at me, though. Once a proposal enters
>> the review stage (and to be clear, this proposal was introduced on behalf
>> of the core team), its fate is out of the hands of the author. What you
>> *can* do is to write and submit a counterproposal to amend and/or reverse
>> the effects of this one, if you deem it necessary. If your objective at
>> continuing this discussion is to convince the core team to re-review the
>> proposal, I'm sure that writing and submitting a counterproposal will be a
>> far more effective way of accomplishing that goal.
>>
>>
>> If this change simplified the compiler a lot it is a positive, but I
>> think there is a void that need to be addressed as I think that mandatory
>> argument labels are an important part of the language and the work by the
>> core team that carried them over from Objective-C and worked even ore on
>> those highlighting their importance in the road to Swift 3.0.
>> This situation now calls as much for fixing the discrepancy as much as
>> removing argument labels everywhere else, it unbalances the syntax IMHO.
>>
>>
>>> 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/20160709/0419dbf6/attachment.html>