[swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels
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>
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution