On Borrow Checking

[Richard (Rikki) Andrew Cattermole]

On 11/05/2025 3:34 AM, Walter Bright wrote:
>     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.
> 
> It does work when you write it. The "second unrelated attribute" (which 
> I assume is the "return" attribute) is necessary to indicate if the 
> scope'd pointer returns or not. Not having the |return| attribute means 
> the following code is impossible to write:
> 
> |int* = foo(scope int* a) { return a; } // error: `a` is escaping via 
> return! scope int* p = ...; scope int* q = foo(p);|

There is also the mess with ``return ref`` vs ``return``, that can be 
written as ``return scope`` and ``scope return``.

These both have the same escape set, just a different relationship strength.

This is of course one of the worst design decisions the D community has 
ever implemented with full regret by all parties involved! :)

This is also a good time to remember that DIP1000 only understands no 
escape, escape into return value OR this pointer. No multiple output 
support, which severely limits its capabilities.