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