--- Comment #9 from Kenji Hara <> 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
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
But, it seems to me that is a special case which reduces the orthogonality and
increase the complexity.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to