On Tuesday, 16 February 2016 at 10:45:09 UTC, Marc Schütz wrote:
On Tuesday, 16 February 2016 at 04:00:27 UTC, Mike Parker wrote:
On Tuesday, 16 February 2016 at 03:39:00 UTC, Matt Elkins
wrote:
On Tuesday, 16 February 2016 at 03:31:51 UTC, maik klein
wrote:
In D you can always call Foo.init even with @disable this(),
Foo.init can be called implicitly (not just explicitly)? If
so, why even have @disable this(), if it offers no guarantees?
IMO, this is a bug. It should have to be explicit, just as it
is with a single struct instance.
There is likely some bug here. In the example, though, the
elements _are_ constructed explicitly (except foos[4]). This is
legitimate, as the first assignment of an element in a
construct counts as construction.
The elements are not constructed explicitly with Foo.init; they
are constructed explicitly with a user-defined Foo constructor.
Since default construction leads to a semantically-invalid object
in the non-reduced case, I was expecting that a @disabled default
constructor would cause the compiler to complain on attempts to
default-construct the struct. Preferably this would be on any
attempt to do so, including explicit calls to Foo.init, but at a
minimum I would want it to complain on attempts to do so
implicitly. Otherwise there don't appear to be any useful
guarantees offered by @disable this().
