If you like, you can try to modify your code as you writes. It is crazy.
> 在 2016年7月10日，00:08，Austin Zheng via swift-evolution > <[email protected]> 写道： > >> >> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> Sent from my iPhone >> >> On 9 Jul 2016, at 00:53, Jon Shier <[email protected] >> <mailto:[email protected]>> 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. > > I'm not inclined to spend time engaging with people who couldn't be bothered > to give feedback during the week-long official review period. > >> >> 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. > >> >> 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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
