This is similar to bug 11286, but slightly different.
Test case:
struct A
{
~this() {}
}
A getA() pure
{
A a; // line 7
return a; // NRVO
}
void main()
{
A a = getA();
}
Output:
test.d(7): Error: pure function 'test.getA' cannot call impure function 'test.A.~this'
In the function getA(), the variable 'a' will be moved out to the caller by NRVO, and its dtor won't be called. So compiler should accept the case properly.
Comment #1 by monarchdodra — 2013-10-17T05:41:32Z
Question:
Doesn't this mean that the compiler *must* implement NRVO? I thought NRVO was an optimization *opportunity*?
If
//----
A getA() pure
{
A a; // line 7
return a; // NRVO
}
//----
Is legal, then it means that only compilers hat implement NRVO will handle this.
Sorry if it's a stupid question.
Comment #2 by k.hara.pg — 2013-10-17T06:48:36Z
(In reply to comment #1)
> Question:
>
> Doesn't this mean that the compiler *must* implement NRVO? I thought NRVO was
> an optimization *opportunity*?
>
> If
> //----
> A getA() pure
> {
> A a; // line 7
> return a; // NRVO
> }
> //----
>
> Is legal, then it means that only compilers hat implement NRVO will handle
> this.
>
> Sorry if it's a stupid question.
Unfortunately current D language spec does not mention about NRVO, so It's still one of the optimizations. But, at least, current dmd always apply NRVO for the specific test case.
And, in D we can check the semantic analysis result by using is(typeof()) and __traits(compiles). I believe that "if these compile-time checker primitives return true, it should mean that the specific D code will generate correct runtime code, and vice versa". For example, since "cannot access frame pointer" error had not been able to detect in compile-time, but now it can.
Back to the case, dmd could generate correct binary for the code by using NRVO. So dmd should not cause "cannot call impure function" error.
Comment #3 by samukha — 2013-10-17T08:12:42Z
(In reply to comment #2)
> Unfortunately current D language spec does not mention about NRVO, so It's
> still one of the optimizations. But, at least, current dmd always apply NRVO
> for the specific test case.
How are the standard library's constructs such as "scoped" supposed to work if NRVO is optional?
Comment #4 by k.hara.pg — 2013-10-17T09:08:07Z
(In reply to comment #3)
> (In reply to comment #2)
>
> > Unfortunately current D language spec does not mention about NRVO, so It's
> > still one of the optimizations. But, at least, current dmd always apply NRVO
> > for the specific test case.
>
> How are the standard library's constructs such as "scoped" supposed to work if
> NRVO is optional?
Yes. std.typecons.scoped requires NRVO in order to implement its own semantic. That's why NRVO should be mentioned properly in language spec.
Comment #5 by verylonglogin.reg — 2013-11-05T08:21:57Z
(In reply to comment #4)
> Yes. std.typecons.scoped requires NRVO in order to implement its own semantic.
> That's why NRVO should be mentioned properly in language spec.
This is Issue 10372.
Comment #6 by robert.schadek — 2024-12-13T18:13:06Z