Copy elision by spec

[Kenji Hara]

2013/11/4 Lars T. Kyllingstad <public at kyllingen.net>

> On Monday, 4 November 2013 at 09:42:53 UTC, Jakob Ovrum wrote:
>
>> On Monday, 4 November 2013 at 07:02:26 UTC, Lars T. Kyllingstad wrote:
>>
>>> I was quite surprised to see that the following program compiles just
>>> fine with DMD:
>>>
>>>    struct S
>>>    {
>>>        @disable this(this);
>>>        int n;
>>>    }
>>>
>>>    S createS(int i)
>>>    {
>>>        S s;
>>>        s.n = i;
>>>        return s;
>>>    }
>>>
>>>    void main(string[] args)
>>>    {
>>>        auto foo = createS(1);
>>>        foo = createS(2);
>>>    }
>>>
>>> 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.
>>>
>>> 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.)
>>>
>>> Lars
>>>
>>
>> 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.
>>
>
> 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.
>
> 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():
>
>   struct Foo
>   {
>       // "Constructor"
>       static Foo opCall()
>       {
>           Foo f;
>           // Initialize f.
>           return f;
>       }
>
>       // Foo should not be copyable.
>       @disable this(this);
>   }
>
>   // Construct a new Foo
>   auto foo = Foo();
>

I think it should be properly mentioned in language spec. Otherwise, we
cannot keep std.typecons.scoped in standard library.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131104/e1abe691/attachment.html>