Confusion regarding struct lifecycle

[Matt Elkins via Digitalmars-d-learn]

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().