<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">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.)</div></div></div></blockquote><div class="">Imho this is no good argument — you can extend it to ban all labels.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div>I'm not sure if I understand this completely:</div><div>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?</div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">The ability to call a function with a tuple containing the arguments</div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div><div class="">In some contexts it's hard to distinguish between "the first parameter" and "the tuple of all parameters", and we have some weird inconsistencies where "foo(x)" and "foo((x))" do the same thing sometimes and different things other times.</div><div class=""><br class=""></div><div class="">There's more complexity here but I don't have it paged in; it's not so relevant to this discussion</div></div></div></blockquote></div>Don't mind — I'm in the lucky position that I don't have to care about the hardships tied to implementation details ;-), so I was just curious if there's danger that the feature will be removed.<div class=""><br class=""></div><div class="">Tino</div><div class=""><br class=""></div><div class="">* I guess it would be a huge one...</div></body></html>