Unfortunately this is currently not a bug. T.init provides "default initialized" object image, and it *does not* provide "default constructed" object. The difference is important.
That is already documented in lanugage reference. http://dlang.org/property#init > Note: .init produces a default initialized object, not default constructed. That means using .init is sometimes incorrect. > 1. If T is a nested struct, the context pointer in T.init is null. > 2. If T is a struct which has @disable this();, T.init might return a logically incorrect object. Kenji Hara 2013/5/20 Maxim Fomin <[email protected]> > 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<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. >
