T.init and @disable this

kenji hara k.hara.pg at gmail.com
Thu Oct 4 04:33:49 PDT 2012


2012/10/4 monarch_dodra <monarchdodra at gmail.com>:
> I'm trying to find out the exact semantics of
>
> @disable this();
>
> It is not well documented, and the fact that it is (supposedly) buggy makes
> it really confusing.
>
> My understanding is that it "merely" makes it illegal to default
> initialization your type: You, the developer, have to specify the initial
> value.
>
> //----
> T t; //initializer required for type
> //----
> Which means, you, the developper, must explicitly choose an initial value.
>
> However, DOES or DOES NOT this remain legal?
> //----
> T t = T.init; //Fine: You chose the initializer T.init
> //----
>
> Keep in mind it is not possible to make "T.init" itself disappear, because
> nothing can be constructed if T.init is not first memcopied onto the object,
> before calling any constructor proper.
>
> I think this should be legal, because you, the developer, is asking for it,
> just the same way one can write "T t = void".

I think that T.init is legal even if T has just only @disable this()
constructor. If not,
> Making it illegal would pretty much make T unmoveable, un-emplaceable,
> un-initializeable on un-initialized memmory, and would probably break more
> than one function/trait which uses "T.init"

But, I also agree that T.init _sometimes_ *unsafe*.
1) If T has @disable this(), T.init will returns an object which just
initialized (== the value itself is never undefined), but not
constructed (might be logically invalid object).
2) If T is nested struct, it's frame pointer is always null. It might
cause access violation by its member function call.

I came up with just now: The use of such unsafe T.init should be
allowed only inside @system/@trusted functions.
I think it is acceptable limitation.

Thoughts?

Kenji Hara


More information about the Digitalmars-d mailing list