Well, now that function type and function signature are officially separate things, we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic. The proposal is incomplete in this regard. It attempts to solve one problem but actually shifts is elsewhere instead.
> I wish the core team or the author of the proposal came to this thread and > engaged again with the community. I am quite sure that they are discussing this internally :) Also, its weekend, let people get some rest! > On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution > <[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 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 >>> <[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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
