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

Xiaodi Wu xiaodi.wu at gmail.com
Thu Jun 30 20:10:53 CDT 2016


On Thu, Jun 30, 2016 at 7:02 PM, Scott James Remnant <scott at netsplit.com>
wrote:

>
> Is there an example of two functions, obeying the naming guidelines, which
>> have different argument labels (not parameter names) for parameters of the
>> same type, where it makes sense to cross-call them?
>
>
> Sure there are. For example, `adding(_:)` and `multiplied(by:)` in the new
> Integer protocol.
>
>
> These have quite different results!
>

Of course they have different results. What's the point of two different
functions that yield the same results? I don't see your point here.
Anywhere I can supply `adding(_:)` as a predicate, I expect to be able to
supply `multiplied(by:)`. Both of these methods take one number and return
another; there is nothing about the label `by` inherent to what the latter
method does; it's entirely an accident of the English language.


>
> I’m pretty convinced that Swift shouldn’t implicitly allow you to assign
> multiplied(by:) to the same member as you could assign adding(_:) -
> explicit is fine, with some syntax e.g. through a closure, but not implicit!
>

But adding(_:) and subtracting(_:) are OK? The point is, with Swift
guidelines, argument labels can differ due to the vagaries of the English
language; it is not a proxy for whether two functions are "not very
different," "somewhat different," or "very different."


> To correct my goofy pre-coffee not-quite-following-the-naming-guidelines
> suggestion, that would be equivalent of allowing these two to be
> interchangeable:
>
>   func drawLineTo(x: Float, y: Float)
>   func drawLineWith(angle: Float, distance: Float)
>
> Which is clearly not something you would expect to be allowed implicitly.
>

Why not? It is not clear to me.


> I’m definitely for the concept of the proposal that this is inconsistent,
> but I’m also definitely for making this explicitly disallowed everywhere,
> not allowed everywhere.
>
> I think Erica makes a good point about syntax too, we’ve been assuming:
>
>   // compatible types
>   var x = drawLineTo
>   x = drawLineWith
>
> but really this isn’t Swifty syntax, the full argument labels provide more
> clarity here; and I’d even be in favor of disallowing the above shortening.
>
> Scott
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/ebd715a1/attachment.html>


More information about the swift-evolution mailing list