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 <[email protected]> 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.
