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.
I hope I won't come across to many completion(true, false,...) + debugging if someone changes the order of the parameters in some branch and another one is merged adding a new call to the closure type with the old order. Looks to me that the problem solved may cause more trouble than what was fixed :/ Sorry for failing at giving my feedback during the review period :( Sent from my iPhone > On 8 Jul 2016, at 12:15 am, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution >> <[email protected]> wrote: >> >> I would also be interested in a clarification on this point from Chris or >> someone else from the core team. >> >> The accepted proposal states that labels are illegal in function types (that >> is also what I was arguing for towards the end of the review discussion) >> but at the same time Cris mentions that cosmetic labels are allowed in >> closure types (which for me is synonymous with function types). So which one >> is it and how does this change affect closure parameters? > > The core team’s intent is that one can add cosmetic labels to function types, > but that those labels are not (cannot be) used at the call site, e.g., > > func foo(fn: (success: Bool) -> Void) { > fn(true) // note: no ‘success:’ argument label > } > > func bar(something: Bool) { } > > foo(bar) // okay: labels not considered > > The proposal should be updated accordingly so it’s clear for future readers. > PR welcome ;) > > - Doug > >> >> Best, >> >> Taras >> >> >>> On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution >>> <[email protected]> wrote: >>> >>> Hey Charlie, >>> >>> The change you reference and this must work together, I have a hard time >>> accepting that we will have a Swift 3 with this change in and no other >>> change that balances it. >>> >>> If this >>> >>> function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) { >>> >>> [...] >>> >>> callback(20,40, true) >>> >>> } >>> >>> is the style we have to use with callbacks from now on, it will be a major >>> regression I would advise a proposal to stop right now. >>> The closure passed around and arriving as a callback there gives me NO clue >>> how to send data to it. How is that for local reasoning? >>> This makes me believe/hope that I am getting it all wrong, so please >>> correct me here :D. >>> >>> If it is not true, then I am blowing things out of proportion and I >>> apologise for this to everyone on the list. >>> >>> >>> Sent from my iPhone >>> >>>> On 7 Jul 2016, at 08:41, Charlie Monroe <[email protected]> wrote: >>>> >>>> There was a fair proposal by Brent >>>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding >>>> the labels to the name of the variable rather than adding it to the type. >>>> And I agree with that since it simplifies the type system. >>>> >>>> Unfortunately, since Swift 3 is making all the code-breaking changed and >>>> Brent's counterproposal is additive, it leaves at least a year-long period >>>> of not having the parameter labels in closures. >>>> >>>> I agree with the change, I don't agree with the timing where it doesn't >>>> have a replacement yet. >>>> >>>>> On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> This feels like making the language a lot worse. Lots of time was >>>>> recently spent bikeshedding methods names and argument labels and this >>>>> proposal bans labels use in some cases and encourage people not to use >>>>> them in others. >>>>> >>>>>> On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> func needsCallback(callback: (a: Int, b: Int) -> Void) { >>>>>> callback(a: 1,b: 2) >>>>>> } >>>>>> >>>>>> >>>>>> func needsCallback(callback: (Int, Int) -> Void) { >>>>>> callback(1, 2) >>>>>> } >>>>>> >>>>>> Is the first one will be forbidden? >>>>>> So you'd like to keep the second one? >>>>> >>>>> I do not understand why someone would want the second example. A great >>>>> point of both Objective-C and Swift was enforcing parameter labels use to >>>>> make the code more readable. >>>>> >>>>> What if that callback were to need width and height? How is that clear >>>>> which parameter I need to pass in which order? >>>>> >>>>> Considering Swift 3 is our last big chance to break code and fixing the >>>>> effects of this proposal would break quite a bit of code again... this is >>>>> a choice it would impact the language for a long time. >>>>> >>>>> >>>>>>> 在 2016年7月7日，11:06，Chris Lattner via swift-evolution >>>>>>> <[email protected]> 写道： >>>>>>> >>>>>>> Proposal Link: >>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md >>>>>>> >>>>>>> The review of "SE-0111: Remove type system significance of function >>>>>>> argument labels " ran from June 30 ... July 4, 2016. The proposal has >>>>>>> been *accepted*: >>>>>>> >>>>>>> The community and core team agree that this proposal will lead to a >>>>>>> simplification and clarification of the type system, as well as a more >>>>>>> clear user model for parameter labels. In response to community >>>>>>> feedback, the core team is accepting the proposal with a revision to >>>>>>> allow “purely cosmetic” parameter labels in closure types for >>>>>>> documentation (as outlined in the alternatives section). The core team >>>>>>> also wants to clarify that a call to a value of closure type would not >>>>>>> allow use of any parameter labels, some interpretations thought that >>>>>>> “arbitrary” parameter labels could be used. >>>>>>> >>>>>>> Thank you to Austin Zheng for driving this discussion forward! I filed >>>>>>> SR-2009 to track implementation work on this. >>>>>>> >>>>>>> -Chris Lattner >>>>>>> Review Manager >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> >> _______________________________________________ >> 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
