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
