2012/10/4 monarch_dodra <[email protected]>: > 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
