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.
