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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > wrote: > >> >> On Jul 9, 2016, at 10:26 AM, Goffredo Marocchi <[email protected]> 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 < >>> [email protected]> 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 < >>> [email protected]> 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 >>>> [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 >>> >>> >>> >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
