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

[Austin Zheng]

On Thu, Jun 30, 2016 at 11:43 AM, Scott James Remnant via swift-evolution <
swift-evolution at swift.org> wrote:

> -1
>
> This proposal doesn’t even use Swift naming style to make its point, as
> soon as you do, the reason why Swift considers argument labels to be part
> of the type signature becomes apparent.
>
> The author of the proposal uses the following example:
>
>   func doSomething(x: Int, y: Int) -> Bool
>
>
> This is just not Swift-y, a much better example would be:
>
>   func sinkBattleship(atX x: Int, y: Int) -> Bool
>
> the proposal states that the argument labels be then stripped from the
> type, which would make this method type-compatible with:
>
>   func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool
>

They already *are* type compatible. This works right now:

var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage
a = sinkBattleship
// ???
a(ofHits: 1, forRuns: 2)


>
>
> I don’t think it’s desirable for this to work at all… Argument labels are
> not parameter names, they are a first class part of Swift’s type system,
> and always meaningful when employed properly.


No they aren't, because of the implicit subtyping demonstrated above. It's
better to remove the significance of argument labels completely than to
vacillate on the topic and make promises we can't actually keep (per that
example).


>
>
> Scott
> _______________________________________________
> 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/fae3d067/attachment.html>