On 12/29/2011 12:29 AM, so wrote:
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr <timon.g...@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?
