Shadowing of members

[comco]

On Wednesday, 9 January 2013 at 22:25:53 UTC, Jonathan M Davis 
wrote:
> On Wednesday, January 09, 2013 23:22:19 Andrej Mitrovic wrote:
>> On 1/9/13, Walter Bright <newshound2 at digitalmars.com> wrote:
>> > It is not a bug.
>> 
>> Something related I want to ask you about:
>> 
>> struct S
>> {
>> int _m;
>> this(int m)
>> {
>> this._m = _m; // meant "this._m = m;"
>> }
>> }
>> 
>> I'd like to add a warning for identity assignments when it 
>> involves a
>> parameter and a field of the aggregate which is the parent of 
>> the
>> function. This was filed as
>> http://d.puremagic.com/issues/show_bug.cgi?id=4407.
>
> Why not just prevent identity assignments altogether? What 
> would be the
> purpose of even allowing a variable to be assigned itself? I 
> see no reason to
> single out parameters or member variables for that.
>
> - Jonathan M Davis

I can forsee someone somewhere having a problem with this if he 
wants to write a general enough templated solution. I actually 
can come up with an example.

Recently I wrote a template mixin witch works this way:
reassign(a, b, c, ...) -> a = b; b = c; ..
Now imagine someone wanting to write a template mixin which given 
local refs and a premutation, permutes them. If the identity 
assignment is not allowed, where he will be in a lot of trouble, 
because he will need to write checks.
In general the identity as a concept should not be 
hard-special-cased. The compiler is free to optimize it.
Of course, in "simple-enough-cases" the prevention might be 
worthwhile. But I still think this is a job of another tool - a 
static code analyzer.