https://issues.dlang.org/show_bug.cgi?id=17213

Johan Engelen <jbc.engelen@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry

--

https://issues.dlang.org/show_bug.cgi?id=17213

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #1 from hsteoh@quickfur.ath.cx ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=17213

Jack Stouffer <jack@jackstouffer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jack@jackstouffer.com

--- Comment #2 from Jack Stouffer <jack@jackstouffer.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=17213

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |safe
                 CC|                            |bugzilla@digitalmars.com

--

https://issues.dlang.org/show_bug.cgi?id=17213

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=17213

--- Comment #4 from Johan Engelen <jbc.engelen@gmail.com> ---
So not a compiler bug then?

--

https://issues.dlang.org/show_bug.cgi?id=17213

Carsten Blüggel <chilli@posteo.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chilli@posteo.net

--- Comment #5 from Carsten Blüggel <chilli@posteo.net> ---
(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?

--

https://issues.dlang.org/show_bug.cgi?id=17213

Carsten Blüggel <chilli@posteo.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--

https://issues.dlang.org/show_bug.cgi?id=17213

--- Comment #6 from Jack Stouffer <jack@jackstouffer.com> ---
(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.

--