[Issue 9732] Do not call opAssign() for the first assignment to member in the constructor

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9732



--- Comment #5 from monarchdodra at gmail.com 2013-03-17 07:49:57 PDT ---
I like this ER, because Contruction != Assignement. I see 0 reasons to call an
opAssign in a constructor. It's just wrong. Being able to clearly make this
distinction is very important (IMO). There are actually a few low level (but
important) bugs in phobos, where an opAssign is called when a constructor
should have been called instead.

On the other hand, I fear that by mixing both notions under the same syntax,
that we'll introduce subtle but hard to find bugs, or confuse users with
complex rules:  how do you document the "first assignment"? What if there is a
run-time "if" in there? What if you make a read of the variable before the
first assignment?

I'm all for such an enhancement (I think it's important), but I'm not sold on
the way it is proposed here.

...

I think I just had a crazy idea: how about allowing a single re-declaration
inside the constructor to explicitly mean constuction as opposed to
destruction. If you do this, then you may not use said field prior to the
re-declaration.

This should be 100% safe, since D bans shadowing.

Examples:

//----
struct S(T)
{
    T a;
    T b;
}

this(??)
{
    T a = ...; //Construc a from ...
    b = ...; //Assign to b from ... over b's initial value
}

this(???)
{
    a = ...; //Imagine initialization of a here, or just use of a here:
    T a = ...; //Error, a has already been used by here
}

this(???)
{
    T a = ...; //OK
    T a = ...; //Error, redeclaration}
}
//----

I think this is both simple, but powerful, and easy to grasp.

It has the added benefit that (unlike C++):
 - You can declare variables and run code before constructing any members.
 - You can defer field construction to any point in time you like.
 - You can construct fields in any arbitrary order.

Thoughts?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------