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
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, 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
@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.
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
Anyway I strongly recommend you to read these documentation pages in order to understand how
If you don't like
scope then don't use it.