http://d.puremagic.com/issues/show_bug.cgi?id=7021
--- Comment #9 from Kenji Hara <[email protected]> 2012-09-21 09:38:44 PDT --- (In reply to comment #7) > Wait. > > @disable this(); > > _is_ the way to disable init. If > > @diasble this(); > > was used, then there should be no init property. That's the entire point of > > @disable this; I think that using T.init does not call any constructors. Therefore any constructor declarations cannot stop its using. ---- I think a struct that has @disable this(); is similar to nested struct that used outside of the valid scope. void main() { struct S { // nested struct int n; void foo(){} } static assert(is(typeof(S.init.tupleof[$-1]) == void*)); // hidden frame ptr check!S(); } void check!T() { T t1; // today this is rejected by fixing issue 8339 T t2 = T.init; // this is still valid assert(t2.tupleof[$-1] is null); // but hidden frame ptr is null // then, t2 is *invalid* object. } On the other hand, even if @disable this(); is declared, init property exists. struct S { @disable this(); // disable default construction this(int n) { // valid construction with a parameter // in here, the memory of 'this' is filled with *S.init*. ...logical initialization of 'this' object with ctor parameters... } } T.init property does not guarantee that the returned object is logically correctly initialized, but it always provides the initial bit representation of T. I think this rule is reasonable also for @disable this(); struct. Of course, you can select a following design: "If struct has @disable this(); *and* no other ctors, init property is also disabled." But, it seems to me that is a special case which reduces the orthogonality and increase the complexity. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
