[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 #11 from Kenji Hara <k.hara.pg at gmail.com> 2012-09-21 19:40:51 PDT ---
(In reply to comment #10)
> It was my understanding that
> 
> @disable this();
> 
> was specifically the syntax to disable the init property. Certainly, trying to
> disable init directly doesn't work as far as I can tell. And since structs
> don't _have_ default constructors, I don't know what else
> 
> @disable this();
> 
> would be disabling (other than perhaps S(), which uses the init property
> anyway, since there's no default consturctor).

I think @disable this(); _does_ disables just a default constructor, and
doesn't disable init property.

As long as I repeated, init property represents a initial state of the object.
(In the language reference, it is called 'default initializer';
http://dlang.org/property.html#init ).
My first point is: init property does not construct anything.

Next, if any constructor is declared in struct S, S(...) is always calls the
constructors, and _should not_ become struct literal expression.
This is my second point. S() would call this(), but it is disabled, then the
compiler show an error so @disable function is used.

The third point is: the first and second are orthogonal. So I can agree that
@disable this();  would forbid a usage of S(), but I don't think that S.init
would also be forbidden.

> The whole point is to be able disable init so that you can _never_ use it for
> _anything_. You must _always_ directly initialize such a type (unless you
> directly initialize it with void).
> 
> Yes, normally, T.init is the value that the type has before any constructor is
> called, but if it's disabled, then it effectively does not exist, and it should
> be impossible to use T.init _anywhere_. Construction should work the same with
> any constructors that do exist (so the object state prior to construction is
> the same as what T.init would have been had it existed), but it should be
> impossible to default initialize such a type or to use it in any context which
> would require default initialization, and it should be impossible to reference
> that type's init in code anywhere. That's the whole point of disabling init,
> and
> 
> @disable this();
> 
> is specifically for disabling init. It doesn't affect declared constructors
> work, but it affects every other aspect of init.

There is a way to disable explicit init property usage.

struct S {
  @disable this();         // disable default construction
  @disable enum int init;  // dummy disabled init property, this is allowed
  ...
}

I think that the usage of S.init is at your own risk. S.init may generate
invalid object, but it is sometimes useful. I hesitate that stopping such usage
by the compiler.

At least, S() would be disabled by @disable this(); declaration. It is the
point of this issue, and my pull request will fix it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------