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!
