[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> ]
This is my feeling as well. Argument labels are definitely part of the name of the function, but they aren’t part of the type. A few functions happen to have argument labels On future directions: I’m mildly in favor of allowing parameters and locals with closure type to have labels in the name: func map<Result>(_ transform(from:): (Element) -> Result) -> [Result] func map<Result>(_ transform: (from: Element) -> Result) -> [Result] which, yes, would require you to rewrite the names if you cared, but would at least allow you to rewrite the names if you cared. More importantly, it lets you document callbacks properly. (This kind of works by coincidence today.) I am in favor of this proposal. Jordan > On Jun 30, 2016, at 11:44, Austin Zheng via swift-evolution > <swift-evolution@swift.org> wrote: > > This is a good point. I feel like calling `x` with any sort of argument > labels should be prohibited. I don't think there's any expressivity penalty > for doing so (especially since tuple splat is gone); plus, once a function is > reified as a value (as opposed to being invoked by naming it directly), I > think the most principled thing to do is to consider the argument labels > "erased". > > (There might be an alternate universe in which Swift's function types' > argument labels are *fully* significant by disallowing conversions between > function values declared with different argument labels, but Swift has never > actually enforced such a requirement, and so it's probably better to just > formalize the semantics as described above than vacillating on whether > argument labels are significant or not.) > > Austin > > On Thu, Jun 30, 2016 at 11:37 AM, Sean Heber via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > This mostly makes sense to me and it seems like mostly a good idea, but take > this example: > > func doSomething(x: Int, y: Int) -> Bool { return true } > let x = doSomething > x(10, 10) > > Is it then legal to do this?: > > x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10) > > That would seem odd to me. Maybe it could be useful, but it might also be > *super* confusing. I’m not sure I have a suggestion as to what to do in a > situation like this - but it doesn’t seem “right” to allow it. > > l8r > Sean > > > > On Jun 30, 2016, at 1:26 PM, Chris Lattner via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > Hello Swift community, > > > > The review of "SE-0111: Remove type system significance of function > > argument labels" begins now and runs through July 4. The proposal is > > available here: > > > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > > > > <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> > > > > Reviews are an important part of the Swift evolution process. All reviews > > should be sent to the swift-evolution mailing list at > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > or, if you would like to keep your feedback private, directly to the review > > manager. > > > > What goes into a review? > > > > The goal of the review process is to improve the proposal under review > > through constructive criticism and contribute to the direction of Swift. > > When writing your review, here are some questions you might want to answer > > in your review: > > > > * What is your evaluation of the proposal? > > * Is the problem being addressed significant enough to warrant a > > change to Swift? > > * Does this proposal fit well with the feel and direction of Swift? > > * If you have used other languages or libraries with a similar > > feature, how do you feel that this proposal compares to those? > > * How much effort did you put into your review? A glance, a quick > > reading, or an in-depth study? > > > > More information about the Swift evolution process is available at > > > > https://github.com/apple/swift-evolution/blob/master/process.md > > <https://github.com/apple/swift-evolution/blob/master/process.md> > > > > Thank you, > > > > -Chris Lattner > > Review Manager > > > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
