Module level variable shadowing

[dennis luehring via Digitalmars-d]

Am 28.06.2014 07:11, schrieb H. S. Teoh via Digitalmars-d:
> On Sat, Jun 28, 2014 at 06:37:08AM +0200, dennis luehring via Digitalmars-d wrote:
>> Am 27.06.2014 20:09, schrieb Kapps:
> [...]
>> >struct Foo {
>> >       int a;
>> >       this(int a) {
>> >           this.a = a;
>> >       }
>> >}
>> >
>>
>> forgot that case - but i don't like how its currently handled, maybe
>> no better way - its just not perfect :)
>
> Actually, this particular use case is very bad. It's just inviting
> typos, for example, if you mistyped "int a" as "int s", then you get:
>
> 	struct Foo {
> 		int a;
> 		this(int s) {
> 			this.a = a; // oops, now it means this.a = this.a
> 		}
> 	}
>
> I used to like this shadowing trick, until one day I got bit by this
> typo. From then on, I acquired a distaste for this kind of shadowing.
> Not to mention, typos are only the beginning of troubles. If you copy a
> few lines from the ctor into another method (e.g., to partially reset
> the object state), then you end up with a similar unexpected rebinding
> to this.a, etc..
>
> Similar problems exist in nested functions:
>
> 	auto myFunc(A...)(A args) {
> 		int x;
> 		int helperFunc(B...)(B args) {
> 			int x = 1;
> 			return x + args.length;
> 		}
> 	}
>
> Accidentally mistype "B args" or "int x=1", and again you get a silent
> bug. This kind of shadowing is just a minefield of silent bugs waiting
> to happen.
>
> No thanks!
>
>
> T
>

thx for the examples - never though of these problems

i personaly would just forbid any shadowing and single-self-assign
and then having unique names (i use m_ for members and p_ for parameters 
etc.) or give a compile error asking for this.x or .x (maybe problematic 
with inner structs/functions)

but that could be a problem for C/C++ code porting - but is that such a 
big problem?