<div dir="ltr"><div class="gmail_extra">Unfortunately this is currently not a bug.</div><div class="gmail_extra">T.init provides "default initialized" object image, and it *does not* provide "default constructed" object. The difference is important.<br>
</div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">That is already documented in lanugage reference.</div><div class="gmail_extra"><a href="http://dlang.org/property#init">http://dlang.org/property#init</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">> Note: .init produces a default initialized object, not default constructed. That means using .init is sometimes incorrect.</div><div class="gmail_extra">> 1. If T is a nested struct, the context pointer in T.init is null.</div>
<div class="gmail_extra">> 2. If T is a struct which has @disable this();, T.init might return a logically incorrect object.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Kenji Hara</div></div><div class="gmail_extra">
<br><div class="gmail_quote">2013/5/20 Maxim Fomin <span dir="ltr"><<a href="mailto:maxim@maxim-fomin.ru" target="_blank">maxim@maxim-fomin.ru</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">On Saturday, 18 May 2013 at 20:39:29 UTC, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 5/18/2013 1:22 PM, deadalnix wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Many are, but I think that isn't the point we are discussing here.<br>
<br>
Removing all holes in @disable this will require the same sacrifices at the ends<br>
than default constructor would. For isntance, what should happen in this case :<br>
<br>
S[] ss;<br>
ss.length = 42;<br>
<br>
if S has @disable this ?<br>
</blockquote>
<br>
Already reported:<br>
<br>
<a href="http://d.puremagic.com/issues/show_bug.cgi?id=10115" target="_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=10115</a><br>
</blockquote>
<br></div></div>
New case, will report it:<div class="im"><br>
<br>
struct S<br>
{<br>
   int a;<br>
   @disable this();<br>
   this(int) { a = 1; }<br>
   ~this() { assert(a !is 0); }<br></div>
   alias a this;<br>
   int opCall() { return a; }<br>
}<br>
<br>
void main()<br>
{<br>
   switch (S.init())<br>
   {<br>
      case 0:<br>
         assert(0); //oops<br>
      default:<br>
   }<br>
}<br>
<br>
By the way, here is another bug.<br>
<br>
I think there is disagreement about @disable reliability and usefulness and similar issues (@safe reliability too) due to different attitude to  the problem:<br>
- 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;<br>
- 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.<br>
- 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.<br>

<br>
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.<br>
</blockquote></div><br></div></div>