Shadowing of members

[comco]

On Wednesday, 9 January 2013 at 20:36:16 UTC, Benjamin Thaut 
wrote:
> After some refactoring I had a series of bugs that came from 
> renaming class members so that the following situation was 
> present.
>
>
> class foo
> {
>   float a;
>
>   void doSomething()
>   {
>     float a;
>     a = a * 2.0;
>   }
> }
>
> The local variable a shadows the member a after the refactoring 
> and therefore this code will no longer work as expected. This 
> was quite time consuming to track down. So I wanted to ask if 
> we want to prevent that with a warning or even an error? D does 
> not allow shadowing of local variables, so why is it allowed 
> for members?
>
> Kind Regards
> Benjamin Thaut

There is a rationale for such checks, but I argue that the place 
of these checks is not in the compiler itself, but in a separate 
tool.
I don't see a reason why we mix up the correct code (which 
compiles) with the non error-prone code (which doesn't do things 
that look buggy). These are two different concepts. D as a 
systems language and (more importantly) as a powerful 
generic-programming-enabled language will need to make 
compromises on both sides. A static code analyzer won't have to. 
I thing an analyzer for such a flexible language would need to 
have different levels of ... pickiness.
I'm giving you java and PMD for example - the static code 
analyzer can be made substantially intelligent in such common 
places.
So, if we had a solid static code analyzer for D, we wouldn't be 
having this discussion at all - just add it as a feature of it.
Which brings me to the question - is there any attempt to build 
such a beast for the D programming language? I think such a 
community driven tool will be of much value for the language 
itself (I learned a lot each time about bad design decisions when 
using the PMD with existing java).
I would argue (but this is a very weak argument) that a decent 
code editor will be able to visually cue you in the easiest of 
situations.