[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

[Austin Zheng]

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 at 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 at 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
> >
> > 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
> >
> > 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
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/c2693ac7/attachment.html>