Hi,
The following seems like a bug to me (reduced code, FILE* changed to int*):

@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.

On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven wrote:

@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
}

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.

On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven wrote:

@safe:
int* fp(return scope int* p) { return p; }
void main()
{
    int* p;
    {
        auto lf = new int;
        p = fp(lf);
    }
    assert(p != null); // address escaped
}

Have the int* inside it to point to a local, or assign another scope int* to it.

On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus wrote:

@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
}

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

I follow your rationale, but for the life of me I cannot see how lf "has global lifetime".

Looks to me like lf is a value instance of the LockedFile struct (so on the stack) in a local scope inside main. I fully agree that the above code is not problematic, but isn't that because p is declared outside this local scope, and the allocation that happens inside the local scope (in the lf constructor) is on the heap, so the allocation (now assigned to p) survives the end of the local scope (and the end of the life of lf) since it is p that has global lifetime?

I don't grok how lf can survive the local scope. Or am I missing something?

On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:

@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
}

[snip]

Perhaps because the local scope is not pushed as a separate (anonymous) function on the stack... if true then, yes, then lf will indeed have the same physical lifetime as main (and p)...?

On the other hand, if you add a destructor to LockedFile, it will be invoked at the end of the local scope, not the end of main.

I find it a bit confusing what the term "lifetime" should pertain to in the case of variables declared inside a local scope inside a function - destructor invocation or physical existence of the variable on the stack?

But this has no bearing on the heap allocation and the lifetime of p in the example.

On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:

You're right, my terminology here is sloppy. I'm really talking about the memory pointed to by lf, not lf itself, so I should really say that lf points to memory with global lifetime (or perhaps "*lf has global lifetime").

On Friday, 25 November 2022 at 17:45:57 UTC, Paul Backus wrote:

Time to use separation logic

😈