[swift-evolution] named parameters

[Jordan Rose]

> On Jan 23, 2016, at 6:02, Tino Heth <2th at gmx.de> wrote:
> 
>>>> If the library author decides to change the internal name, it's now a source-breaking change for clients. (Alternately, all the existing internal names are now external names, without any thought given to them, which would be just as bad.)
>>> Imho this is no good argument — you can extend it to ban all labels.
>> 
>> No, that's not the case. External names are part of the method name and signature and are part of the source and binary interface for a library. Internal names are local variables with a little bit of documentation. Every parameter has both internal and external names; it's just that the logic for what happens when you only specify one that's different.
> I'm not sure if I understand this completely:
> When each parameter has an external and an internal name, changing the latter should never be an issue for users of that method… where's the fault in my logic?
> The "only"* breaking change I see happens when the behavior for all parameters is unified, and suddenly parameters without external name (or "empty external name"...) would receive one.

Sorry, I thought you were suggesting that if an external name were not specified, the internal name would be optionally allowed at the call site. I see now that you were proposing to first make all parameters have external names by default, and then to make the label optional.

I still disagree with this, but it doesn't break anything. :-)

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/837921a1/attachment.html>