Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
February 20, 2017 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17213 Johan Engelen <jbc.engelen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |industry -- |
February 20, 2017 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
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. -- |
April 03, 2017 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
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. -- |
April 12, 2017 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17213 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |safe CC| |bugzilla@digitalmars.com -- |
April 12, 2017 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
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. -- |
May 22, 2017 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17213 --- Comment #4 from Johan Engelen <jbc.engelen@gmail.com> --- So not a compiler bug then? -- |
January 20, 2018 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
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? -- |
February 06, 2018 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=17213 Carsten Blüggel <chilli@posteo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID -- |
February 06, 2018 [Issue 17213] [REG2.072] take address of ref return value @safe | ||||
---|---|---|---|---|
| ||||
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. -- |
Copyright © 1999-2021 by the D Language Foundation