Am 07. Juli 2016 um 10:10 schrieb Goffredo Marocchi via swift-evolution 
<swift-evolution@swift.org>:


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.


That would indeed be a major regression :-(



-Thorsten





 
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 <char...@charliemonroe.net> 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 
<swift-evolution@swift.org> 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 
<swift-evolution@swift.org> 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 <swift-evolution@swift.org> 
写道:


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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution



_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to