New attribute to control references

[Loara]

On Wednesday, 27 April 2022 at 14:58:12 UTC, Dennis wrote:
> 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?

It could initialize the stack allocated pointer to `null` if no 
argument is passed, but it could be also a `@trusted` function, 
this is not the point, the point is that with a not transitive 
`scope` it's still possible to transfer references to non `scope` 
pointers without explicit casts.

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

I admit the `return scope` attribute is a bit esoteric for me, I 
need to study it better.

> 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?

Originally I wrote these articles in order to specify how to 
implement a transitive `scope` attribute, but this would be too 
restrictive if the primary scope of `scope` is to allow stack 
allocation of objects. A transitive scope is more appropriate for 
`synchronized` access to a `shared` variable that contains 
indirections rather than a stack allocated object. But these are 
only my personal opinions.