pointer escaping return scope bug?

[Paul Backus]

On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven 
wrote:
> Hi,
> The following seems like a bug to me (reduced code, FILE* 
> changed to int*):
> ```d
> @safe:
>
> struct LockedFile
> {
>     private int* fps;
>
>     auto fp() return scope => fps;
> }
>
> void main()
> {
>     int* p;
>     {
>         auto lf = LockedFile(new int);
>         p = lf.fp;
>     }
>     assert(p != null); // address escaped
> }
> ```
> There's no error with -dip1000.
> I'll file this unless I overlooked something.

I think this is intended behavior, because you *do* get an error 
if you replace `new int` with a pointer to a stack variable; e.g.,

     int local;
     auto lf = LockedFile(&local);

The `return scope` qualifier on the method does *not* mean "the 
return value of this method is `scope`". It means "this method 
may return one of this object's pointers, but does not allow them 
to escape anywhere else." In other words, it lets the compiler 
determine that the return value of `lf.fp` has *the same* 
lifetime as `lf` itself.

Since, in your example, `lf` has global lifetime, the compiler 
deduces that `lf.fp` also has global lifetime, and therefore 
there is nothing wrong with assigning it to `p`.