Deprecating this(this)
ag0aep6g
anonymous at example.com
Tue Apr 3 14:21:33 UTC 2018
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?
More information about the Digitalmars-d
mailing list