On Borrow Checking

[Richard (Rikki) Andrew Cattermole]

On 12/05/2025 11:16 PM, Manu wrote:
> On Mon, 12 May 2025 at 21:10, Richard (Rikki) Andrew Cattermole via 
> Digitalmars-d <digitalmars-d at puremagic.com <mailto:digitalmars- 
> d at puremagic.com>> wrote:
> 
>     On 12/05/2025 10:55 PM, Manu wrote:
>      > `scope` shouldn't depend on @safe, and Walter above said it depended
>      > only on -dip1000.
>      > So, if it only works with @safe, I repeat again; WHY? It's not only
>      > redundant annotation, but it's also a ticking bomb waiting to
>     explode...
>      > I already commented on this.
> 
>     @safe is the static analysis on a function that the compiler guarantees
>     is memory safe.
> 
> 
> `scope` has nothing to do with @safe. I want to prohibit the callee 
> retaining the argument; simple as that.

Use @safe.

@system and @trusted simply do not, and will not have these guarantees.

There must be an escape hatch, and those are what D has it defined as.

>     @trusted is the escape hatch where you have to do something that the
>     compiler cannot make guarantees for.
> 
> 
> This has nothing to do with @safe.
> 
>     @system has no guarantees associated with it.
> 
>     All scope says is that this variable will not escape this function.
> 
> 
> Exactly. Nothing to do with @safe.

It has everything to do with @safe, that is where the mechanical checks 
exist.

You do not need the escape set (``scope``), if you do not have the 
mechanical checks, and where you have an escape hatch (``@trusted`` and 
``@system``), these are intentionally not turned on.

>     It is not redundant information, it does serve an important purpose in
>     escape analysis.
> 
> 
> Incorrect.

I have spent the last couple of years studying escape analysis, along 
with what attributes mean when they are missing specifically due to 
DIP1000's ``return scope`` and ``scope return`` mess.

Not only this, but I know enough of the DFA theory including what 
clang-analyzer does for frontend analysis to have been implementing that 
in dmd.

It is not redundant, this is a defining trait of how this stuff works.

>     When you see no attributes, think unknown escape behavior, it is not
>     modeled. Not, this doesn't escape, or it escapes into an unknown
>     location. These are all different things.
> 
> 
> Okay, I'll repeat for the 3rd time or so; when `scope` is annotated to 
> an argument, it MUST have effect, otherwise an escape related crash is 
> inevitable that the user intended to prevent, and when they start 
> debugging and trying to track down the issue; they will see the `scope` 
> annotation, assume it's not that, then move on to continue looking in 
> the wrong place for their issue.

Okay agreed.

We should disallow it for @system functions, they do not interact with 
any static analysis in any way.

> `scope` has nothing to do with @safe, and it MUST work in its own right, 
> otherwise the code is lying to the author, and it's an effective liability.

No, it is auxiliary lint level annotation on variables.

It is not a type qualifier and is not checked in the type system itself.

Data flow analysis in a frontend is lint level, it works after the rest 
of compilation has been completed. It adds information, but it doesn't 
mess with the type system itself, if it adds information it wants to 
check within the type system, DFA is responsible for doing the checks, 
not the type system. The distinction matters.