Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[Maxim Fomin]

On Saturday, 18 May 2013 at 20:39:29 UTC, Walter Bright wrote:
> On 5/18/2013 1:22 PM, deadalnix wrote:
>> Many are, but I think that isn't the point we are discussing 
>> here.
>>
>> Removing all holes in @disable this will require the same 
>> sacrifices at the ends
>> than default constructor would. For isntance, what should 
>> happen in this case :
>>
>> S[] ss;
>> ss.length = 42;
>>
>> if S has @disable this ?
>
> Already reported:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10115

New case, will report it:

struct S
{
    int a;
    @disable this();
    this(int) { a = 1; }
    ~this() { assert(a !is 0); }
    alias a this;
    int opCall() { return a; }
}

void main()
{
    switch (S.init())
    {
       case 0:
          assert(0); //oops
       default:
    }
}

By the way, here is another bug.

I think there is disagreement about @disable reliability and 
usefulness and similar issues (@safe reliability too) due to 
different attitude to  the problem:
- As a language designer I care about whether some feature is 
claimed to solve some problem - and that all, I put it on a slide 
as lang advantage;
- As a programmer who writes medium importance code I care 
whether the feature stops me from making bugs unintentionally. If 
it does, than I consider that the feature works.
- As a programmer who writes critical code I care whether feature 
prevents from problem, even made deliberately, and if it doesn't, 
than the feature isn't reliable. It doesn't mean that it is 
totally useless, but it does mean that its reliability 
commitments are cheap.

Since in system language there is plenty of ways to deliberately 
pass invalid data to the place where some validity assumptions 
were made, @disable is a broken feature.