On 04/03/2018 10:21 AM, ag0aep6g wrote:
On Tuesday, 3 April 2018 at 12:52:00 UTC, Andrei Alexandrescu wrote:
On 04/03/2018 07:36 AM, ag0aep6g wrote:
For constructors, we say that the first assignment is actually
initialization. The compiler might or might not put the .init value
down before calling the constructor. Doesn't matter, because the
constructor will overwrite it anyway, and nothing of value is lost.
What happens in fact is you are guaranteed the .init value is there.
Much later, well after semantic checking, the backend optimizer
removes dead assignments on primitive data.
So constructors, including const/immutable ones, basically work the same
as postblit already? You get an object pre-filled with some values, and
then you can "initialize" the fields some more if you want.
Well... not really. This is because .init is really an inert state -
null indirections, no state allocated etc. Makes typechecking easy, and
calling constructor on top of .init is what happens already. In
contrast, the postblit situash is very different - the fields already
contain "interesting" data, allocated resources etc. Calling a
constructor on top of that is not defined.
