<div dir="ltr">2013/11/4 Lars T. Kyllingstad <span dir="ltr"><<a href="mailto:public@kyllingen.net" target="_blank">public@kyllingen.net</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 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 Monday, 4 November 2013 at 09:42:53 UTC, Jakob Ovrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Monday, 4 November 2013 at 07:02:26 UTC, Lars T. Kyllingstad wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I was quite surprised to see that the following program compiles just fine with DMD:<br>
<br>
   struct S<br>
   {<br>
       @disable this(this);<br>
       int n;<br>
   }<br>
<br>
   S createS(int i)<br>
   {<br>
       S s;<br>
       s.n = i;<br>
       return s;<br>
   }<br>
<br>
   void main(string[] args)<br>
   {<br>
       auto foo = createS(1);<br>
       foo = createS(2);<br>
   }<br>
<br>
I already knew that the compiler was allowed to elide copies on return from functions, but I thought this was an optimisation, and not part of the language proper.  I would have expected the compiler to complain that createS() can't return an S since S's postblit constructor is disabled.<br>

<br>
My question is therefore, is this by design?  Can I rely on this to work in the future, and on all compilers?  If this is the case, it really should be added to the spec.  (Or maybe it's there already, but I couldn't find it.)<br>

<br>
Lars<br>
</blockquote>
<br>
My understanding is that your example illustrates a *move*, not a *copy*. AFAICT, non-copyable structs would be next to useless if we couldn't move them.<br>
</blockquote>
<br></div></div>
I know, and I agree.  The question is whether this is a move *by specification*, i.e. whether the language makes a guarantee that return values are always moved under certain circumstances.  If so, this should be mentioned in the spec, along with a detailed description of said circumstances.<br>

<br>
I am using this "feature" in a program I'm working on right now.  It would be a shame if this is a mere DMD artifact, as opposed to a language feature, because then I can't depend on it working in other compilers or in future DMD versions.  I really don't know any other way to solve my problem either, so I'm keeping my fingers crossed that this can become part of the official spec.  For anyone interested, the actual use case is a no-arguments constructor for a non-copyable struct, emulated with static opCall():<br>

<br>
  struct Foo<br>
  {<br>
      // "Constructor"<br>
      static Foo opCall()<br>
      {<br>
          Foo f;<br>
          // Initialize f.<br>
          return f;<br>
      }<br>
<br>
      // Foo should not be copyable.<br>
      @disable this(this);<br>
  }<br>
<br>
  // Construct a new Foo<br>
  auto foo = Foo();<br>
</blockquote></div><br></div><div class="gmail_extra">I think it should be properly mentioned in language spec. Otherwise, we cannot keep std.typecons.scoped in standard library.<div><br></div><div>Kenji Hara</div></div>
</div>