> On Jun 30, 2016, at 9:36 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > [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.)
This *might* make sense. I almost included something similar in my review. It is one of the use cases I had in mind when I mentioned the possibility of designing a less fragile feature for specific uses cases. But that discussion is for the future. :) > > I am in favor of this proposal. > > Jordan > >> On Jun 30, 2016, at 11:44, Austin Zheng via swift-evolution >> <swift-evolution@swift.org <mailto: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 <mailto: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
