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.
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.
(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.
(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?
(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.
(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.
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18699 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB