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

Austin Zheng austinzheng at gmail.com
Mon Jul 4 01:52:20 CDT 2016

> On Jul 3, 2016, at 11:50 PM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> Overall, -1.
> I agree that labels should not affect the type, but imho the current status (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't achieve what it says in the title:
> For me, that is no question of types at all, but only of names:
> var a: (Int, z: Int) -> Void = t
> var b: (y: Int, z: Int) -> Void = t
> a = b
> This works, because a and b are both of type (Int, Int) -> Void, and the labels aren't significant.

The point of the behavior is to remove the subtyping relationships from the type system which make the above work, which is a very real change.

> So the proposal merely disallows labels in the declaration of function variables, which I consider bad, because labels convey the meaning of parameters. Why should something that is widely seen as a good feature of functions be removed from function variables?

As has been discussed exhaustively in this thread, Swift 3 function labels don't convey the meaning of parameters, they are almost always prepositional phrases that don't make sense apart from the primary function name they are attached to.

> If you share the opinion that labels are part of the name, the battleship example no good argument against labels:
> No one stops you from doing
> let minimum: (Int, Int) -> Int = max
> Which is confusing as well.
> Best regards,
> Tino
> _______________________________________________
> 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/20160703/b4538019/attachment.html>

More information about the swift-evolution mailing list