Andrei Alexandrescu:
I'll note that fixing this bug is more difficult than it might
seem,
particularly when immutable members and immutable constructors
come into
play.
Some flow control is needed. At start each member variable of
the object
starts in a "raw" state. The constructor code progressively
assigns to
members, putting them in a "cooked" state.
Although the syntax looks like assignment, the constructors
should be
called for struct members.
A "cooked" member cannot be assigned to again.
No function call that takes this (including members) is allowed
until
all members have become "cooked".
If the constructor was const or immutable, the object
effectively
becomes const or immutable exactly at the point all members are
"cooked". At that point in the constructor, the object or its
members
can be passed to functions.
That reminds me of this approach to implement non-nullables:
http://research.microsoft.com/pubs/67461/non-null.pdf
Bye,
bearophile
