[swift-evolution] [Idea] Omit argument labels from the call site when the argument is the same as the label

[Alex Hoppen]

Looks OK to me, but still I don't like the fact that the name of a local variable can change whether or not this expression is ambiguous. Basically, the function call blocks certain variable names which the caller cannot use without escaping them using "_:". To me it feels like the function definition can introduce some kind of keyword and that seems weird to me. But that's of course a matter of taste.

- Alex

> On 07 Feb 2016, at 23:06, Kenny Leung <kenny_leung at pobox.com> wrote:
> 
> What if the compiler forced you to disambiguate by writing
> 
> myPrint(_:withTwoDecimals)
> 
> if you wanted to call "func myPrint(number: Double) { }”
> 
> -Kenny
> 
> 
>> On Feb 7, 2016, at 12:41 PM, Alex Hoppen <alex at ateamer.de> wrote:
>> 
>> I don’t think it is possible to implement this without major changes to the way function overloads are selected.
>> 
>> Consider the following example with where there are multiple functions that can print a Double (yes, the external arguments could be put in the function’s name, but I hope it shows my point):
>> 
>> func myPrint(number: Double) { }
>> func myPrint(withTwoDecimals number: Double) { }
>> func myPrint(withThreeDecimals number: Double) { }
>> 
>> Currently all three of these functions have different signatures. If your syntax would be implemented in Swift, then
>> 
>> myPrint(withTwoDecimals)
>> 
>> would be ambiguous. 
>> 
>> Defaulting to the function without external parameter names in case of ambiguity isn’t an option because then the call would change its behaviour the moment a library adds myPrint(number: Double) in addition to the other functions. This is definitely not desirable! The same applies for defaulting to the function with the external parameter name.
>> 
>> I don’t like leaving the function call ambiguous because then the only way to call myPrint(number: Double) would be to change the name of the variable. The name of any variable should by private and therefore not have any effect on how the function is called. (Also think about functions where there is basically only one proper way to name a variable, like x for coordinates. You would have to rename the variable which leads to less descriptive variable names).
>> 
>> Thus, the only way to resolve this issue IMO would be to say that the signatures myPrint(number: Double) and myPrint(withTwoDecimals number: Double) are identical. Then, however, the signatures of myPrint(withTwoDecimals number: Double) and myPrint(withThreeDecimals number: Double) would need to be equivalent as well, which seriously limits the way functions can be overloaded in Swift. I don’t think that the improved syntax is worth paying with the this expressiveness of function overloads.
>> 
>> - Alex
>> 
>>> On 07 Feb 2016, at 20:45, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Hi All.
>>> 
>>> I’m just throwing this out there.
>>> 
>>> often when I write Objective-C, my method calls end up looking like this:
>>> 
>>> [you doYourThingWithThis:this that:that these:these those:those other:other];
>>> 
>>> This reads poorly and requires extra typing. It would be nice if the compiler just assumed that when no label is given, the label is the same as the argument name. The code would be just as understandable (more) than if the argument labels were actually there.
>>> 
>>> In Swift, this:
>>> 
>>> you.doYourThingWithThis(this, that:that, these:these, those:those, other:other)
>>> 
>>> becomes
>>> 
>>> you.doYourThingWithThis(this, that, these, those, other)
>>> 
>>> However, if you are the type that likes to name your variables a,b,c,d, no harm done, since then labels would be required, and it would still read OK
>>> 
>>> you.doYourThingWithThis(a, that:b, these:c, those:d, other:e)
>>> 
>>> -Kenny
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2366 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/db26a396/attachment.p7s>