On Thursday, 30 June 2022 at 21:30:39 UTC, Ola Fosheim Grøstad
wrote:
I don't understand what you mean, it could, but it doesn't. And
if it did then you would not need `scope`…
If the compiler doesn't optimize your code is a compiler issue.
When you use the `scope` attribute you're [forcing the compiler
to do a stack
allocation](https://dlang.org/spec/attribute.html#scope-class-var), so the compiler forbids you from doing something stupid.
These are function pointer parameters, how could it trigger
allocation on the heap?
When you declare `scope` function parameters you're saying that
it may point both to heap allocated and stack allocated data, and
the compiler choose the more restrictive option when it compiles
your option, since at that time it doesn't know if your function
arguments are heap allocated or stack allocated.
But that doesn't work.
But you first said "The compiler should deduce if a `scope`
pointer points to heap allocated data or not" and when someone
tells you this should happen only for not `scope` pointers you
say "But the compiler doesn't do that".
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.
No-one forbids you from writing an unsafe function that does
unsafe operations, the `@system` and `@trusted` attributes are
available yet. Simply you should control very well your code in
order to avoid memory leaks and other issues since memory
management without garbage collectors can't be safe without
introducing a lot of restrictions.
If you decide to do so I recommend you this [very useful
tool](https://valgrind.org/).
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.
If you want the compiler to optimize your code you should remove
any additional restriction, and declaring a pointer `scope` is an
additional restriction not a relaxation. If you don't like it
then you can always build a new compiler that do this if you need
it so much, this is how open source software works.
But then it won't compile at all in @safe!
Find me an example of safe code that needs it and can't work
without `scope` variables.
Anyway I strongly recommend you to read these
[documentation](https://dlang.org/spec/attribute.html#scope)
[pages](https://dlang.org/spec/function.html#scope-parameters) in
order to understand how `scope` works.
If you don't like `scope` then don't use it.
