Bug 17213 – [REG2.072] take address of ref return value @safe

This code compiles with 2.071, but not with 2.072 nor 2.073: ``` struct S { int i; auto ref foo() @safe { return i; } auto bar() @safe { return &foo(); // <-- Error } } void main() { auto s = S(); s.bar(); } ``` The error is: "cannot take address of ref return of this.foo() in @safe function bar". Is this a compiler regression, or is it a bug in the D code?

I think this is by design of DIP1000. Unfortunately, I couldn't seem to find any combination of `scope` or `return` annotations that would work around this particular case. Seems to be a true (and breaking!) limitation of DIP1000.

(In reply to hsteoh from comment #1) > Seems to be a true (and breaking!) limitation of DIP1000. The idea of having a -dip1000 switch was to make it so normal code won't be hit with changes like this. The problem is that for some reason we're breaking user code that has nothing to do with dip1000. Which, without a deprecation cycle, is unacceptable.

It's never been legal to take the address of a 'ref' in @safe code - it's a compiler bug that that was ever allowed. The compiler will allow it if bar() is marked as @trusted.

So not a compiler bug then?

(In reply to Johan Engelen from comment #4) > So not a compiler bug then? My understanding is, that Walter Bright's comment is comprehensive, replying to the issue and (indirectly) to other points raised here, in my words: - The language doesn't allow to take the address of a 'ref' in @safe code, enforced since 2.072 (as always, manual safety check and @trusted is possible). - unrelated to DIP1000 Did I miss anything or why is this issue still an open regression?

(In reply to Carsten Blüggel from comment #5) > Did I miss anything or why is this issue still an open regression? The idea is that it shouldn't have been an error, but a deprecation. Since we're a couple of releases past this now it's too late to fix.