DIP1000

[Loara]

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.