DIP1000

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Thu Jun 30 21:30:39 UTC 2022


On Thursday, 30 June 2022 at 19:56:38 UTC, Loara wrote:
> The deduction can happen even if you don't use `scope` 
> attribute.

I don't understand what you mean, it could, but it doesn't. And 
if it did then you would not need `scope`…

> When you use `scope` attribute you're saying to compiler "You 
> have to allocate this object on the stack, don't try to use 
> heap allocation".

These are function pointer parameters, how could it trigger 
allocation on the heap?

> If you want to let compiler to decide what is the best approach 
> then don't use `scope`.

But that doesn't work.

> So `scope int v;` is equal to `int v;` since `v` is not a 
> pointer, whereas `scope int *p` is different from `int *v;` 
> since the latter can't point to stack allocated integers. This 
> is the difference.

No, the latter can most certainly point to any integer. It is 
just that scope/scope ref/return ref is to be checked in @safe. 
Unfortunately it is way too limiting. Even standard flow typing 
appears to be as strong or stronger.

> Since stack allocated objects are destroyed in the reverse 
> order allowing a recursive `scope` attribute is a bit dangerous 
> as you can see in the following example:

If there are destructors then you can think of each stack 
allocated variable as introducing a invisible scope, but the 
compiler can keep track of this easily.

So the compiler knows the ordering. So if my function imposes and 
order on the lifetimes of the parameters, then the compiler 
should be able to check that the ordering constraint is satisfied.

> Again if you want to let the compiler to deduce then don't use 
> `scope`.

But then it won't compile at all in @safe!



More information about the Digitalmars-d-learn mailing list