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.
[...]
What if the user code reads the value?
* Often people use this(this) to bump a reference count a la
"if (pcnt) ++*pcnt;"
Because of the indirection, that can only be done in a mutable
`this(this)`. Otherwise you violate the const/immutable guarantee
of the original object.
* People may pass the field by reference to an opaque function.
What type does the field have?
Fully const. Same as in a constructor.
[...]
In case (1) things can get quite confusing. Inside a postblit,
field = TypeOfField(100);
is a call to the constructor, whereas
field = TypeOfField(field.x + 100);
is a call to the assignment operator.
A const constructor currently accepts both of those. So the
second one can apparently be considered "initialization" as well?
Or should a const constructor not be allowed to do that?
