simple DIP1000 test fails?

[Jonathan M Davis]

On Thursday, November 02, 2017 16:39:43 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 11/2/17 4:07 PM, Jonathan M Davis wrote:
> > On Thursday, November 02, 2017 14:03:52 Jonathan M Davis via
> > Digitalmars-d->
> > learn wrote:
> >> On Thursday, November 02, 2017 19:53:36 Q. Schroll via
> >> Digitalmars-d-learn>>
> >> wrote:
> >>> struct S { ref S id() return { return this; } }
> >>> void main() { S* p = &S().id(); }
> >>
> >> Well, if you make them @safe, it won't compile whether -dip1000 is used
> >> or not. At the moment, I don't recall whether -dip1000's effects are
> >> supposed to be limited to @safe code or not though. If they are, then
> >> I don't think that there's a bug, but if they aren't, then it looks
> >> like there is.
> >
> > Though actually, scope isn't used anywhere here, and IIRC, -dip1000 only
> > comes into affect when scope is used. So, I don't think that -dip1000
> > really applies here. But I'm not as well-versed in the ins and outs of
> > DIP 1000 as I should be, so I could be wrong.
>
> The issue here is that rvalues bind to the `this` reference. I think
> this is actually dip25, and it's definitely a bug. Whatever kicks in
> when dip25 is enabled (tried -dip25 and -dip1000 switch, and it still
> compiles) is not understanding the lifetime of the rvalue in order to
> properly apply it to the resulting ref.

Except that IIRC, DIP 25 only applies to @safe code. I haven't read DIP 25
recently, but I assume that the return on id is equivalent to marking the
this parameter with return, in which case, the compiler knows where the
returned reference came from. So, returning by ref shouldn't be a problem.
The problem is simply taking the address, since the S is a temporary, and
that's already caught by @safe even without compiling with -dip25.

So, unless I'm remembering wrong, and -dip25 actually applies to @system
code as well, then I don't think that this is a bug in -dip25.

- Jonathan M Davis