2013/11/4 Lars T. Kyllingstad <pub...@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
