A nice way to step into 2012

[Timon Gehr]

On 12/29/2011 12:29 AM, so wrote:
> On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 12/28/2011 11:34 PM, so wrote:
>>> If you change "anything" in your interface, it is already a breaking
>>> change.
>>
>> That is why it is desirable to not let parameter names contribute to
>> the interface. Jonathan definitely has a point against making all
>> parameters named parameters by default.
>
> /// A.d
> void fun1(int Arg);
> void fun2(int x);
>
> /// B.d
> void fun1(int arg);
> void fun2(int y);
>
> I am having hard time understanding the issue really.
> Now as a user i don't know why the library dev. changed the interface:
>
> /// without NP
> fun1(arg); // recompile no edit,
> fun2(x); // well
>
> You are saying like changing a parameter name in lib code is always so
> harmless.
> You guys making your case on a dumb developer that goes for a breaking
> change just to fix a always harmless typo.

I have a hard time understanding your case. You wrote /// without NP. 
Without NP it is perfectly reasonable to fix the typo and there is no 
breaking change. That is part of why having no NP by default is 
desirable. The moment NP by default is introduced is the moment all 
parameter names in all libraries are set in stone. Those names were mere 
implementation details prior to that point in time.
Having parameter names contribute to the interface means that all 
developers need to spend time thinking about the best possible names for 
their function parameters.

> Then, what makes you so sure he won't do this?

What makes you so sure that if he does, he actually remembers to change 
the functionality too?