On Sun, 4 May 2025 at 05:15, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 5/2/2025 12:44 AM, Manu wrote:
> On a slight tangent; why do I need to attribute the function at all for it to
> check `scope` args don't escape?

Because otherwise the compiler has to examine the function implementation to
verify this. Doing such is called attribute inference, and D does quite a bit of
that. Problems are:

1. Function declarations don't have a body, so there's no way to inspect the body.

A prototype without a body must always trust the declaration. You must simply assume that presence of `scope` on an arg asserts that the parameter won't be retained by the call, and the caller can also bank on that fact; ie, using temp/stack memory to allocate an argument.

2. Inspecting all the bodies means compilation gets slowed down quite a bit.

If you don't want escape analysis, don't write `scope`; point is, why do you need to write TWO attributes together for the first one (which is itself strictly optional) to take effect?

3. Chicken-and-egg problems when inferring attributes when there are loops in
the function call flow graph.

I don't follow.
Is it something like; a template which receives an arg but doesn't explicitly state `scope` just spend time to try and infer `scope` because a caller of that template may rely on that attribute inference?

> I do want to add `scope` to pointers and ref arguments, but I don't see any
> reason that I should have to attribute `live`... why isn't `scope` enough to
> enable escape analysis?

The DFA (Data Flow Analysis) required to determine whether a pointer is the
"owner" or not at each point in the function is considerably more complex than
just checking for scope-ness. DFA equations are generated and then solved
iteratively.

The code required to do it is:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ob.d

which is very similar to the DFA performed by the optimizer:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/gflow.d

Yeah but I still don't get it; if you don't want escape analysis, don't write `scope`. If you do write it, you have clearly and unambiguously indicated that you DO want escape analysis, so it should happen.
I can't see any reason a second unrelated attribute should be required in conjunction to make the first one work... you write `scope` thinking it will be effective, and then by not writing (or forgetting to write) the other thing, your code is now lying to you. You won't know this until you are bitten by the escape bug that you were trying to prevent; making the sutuation actually *worse* than useless, because when you're trying to track down your bug, you will see the attribute, and continue looking elsewhere.
`scope` should work when you write it; period. If that is to say that writing `scope` infers the other attribute, whatever... but it's not a reasonable situation where `scope` silently does nothing and confuses or misleads the author.