http://d.puremagic.com/issues/show_bug.cgi?id=9732
--- Comment #5 from monarchdo...@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: -------
