New attribute to control references

[Dennis]

On Monday, 25 April 2022 at 16:06:00 UTC, Loara wrote:
> https://github.com/Loara/Rethink_scope_in_D/blob/main/README.md

The first section notes that DIP1000's documentation is lacking, 
which is true and something I'm working on (see for example 
https://github.com/dlang/dlang.org/pull/3284).

It then mentions the lack of transitive scope, a known 
limitation, but with a curious example:
```D
scope int **b = stack_allocate!(int *)();
```
How would that function return a non-dangling stack pointer?

> A simple solution could be force scope variables to be used 
> only as scope function parameters (...) but in this way we've 
> made set completely useless, why we have to define a set 
> function if we can't use it to set a member?

Indeed, that's how it currently works, so you can't assign 
`scope` variables to a class field because `scope` only applies 
to the class reference itself. You can make a `set` function for 
a struct by marking the `p` parameter `return scope`.

> So the scope attribute is not what the manual-memory managment 
> fans are waiting [for]

That's assuming the given examples are representative of actual 
code. They could be, but personally, I usually only manually 
manage flat arrays.

I know the current `scope` storage class leaves some things to be 
desired, but I don't understand why you propose a completely new 
attribute. Can a 'transitive scope' extension also suffice?