[Issue 7021] Structs with disabled default constructors can be constructed without calling a constructor.

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7021



--- Comment #9 from Kenji Hara <k.hara.pg at gmail.com> 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: -------