On Thursday, 10 January 2013 at 03:38:23 UTC, Jonathan M Davis
wrote:
On Thursday, January 10, 2013 04:24:26 deadalnix wrote:
This argument can go on and on forever. What about getting some
hard data ?
We should start to gather data when considering such issue.
What
about adding the warning in some dmd version and trying it on
several codebase to get a good view of the impact of such a
change ?
1. Walter has already rejected this idea.
2. Do you honestly think that it's not incredibly common to
declare
constructor parameters to have the same names as the member
variables that
they go with? Who _doesn't_ do it that way? The only thing that
would mitigate
how often it would be warned about would be how many POD types
in D get away
without needing to define constructor, because one is
implicitly declared. It's
incredibly common practice in C++, Java. C#, etc. to name
constructor
parameters after the member variables that they go with. If
anything, it's
rare _not_ to do that (aside from private member variables
often having stuff
like _ or m_ added to them).
3. Why on earth would I want the compiler to be warning me
about the variable
names that I pick? No offense. But that's asinine. There are
_no_ bugs in code
like
struct S
{
this(int a, int b)
{
this.a = a;
this.b = b;
}
int a;
int b;
}
There aren't even any _potential_ bugs in that code. It's
perfectly sound.
Warning about something like
a = a;
would make some sense. Warning against a perfectly valid
assignment or the
fact that the variable names happen to be the same is just
stupid.
Warning about something which isn't a bug or at least almost a
guarantee to be
a bug is _not_ a valid use of a warning IMHO. You don't have
warnings for good
or bad practice. You have warnings for likely bugs. And I
wouldn't even
consider the struct above to be bad practice anyway.
- Jonathan M Davis
So authority argument worth more than actual data. That is noted.
