dip1000 and preview in combine to cause extra safety errors

jmh530 john.michael.hall at gmail.com
Thu Jun 9 15:38:10 UTC 2022


On Thursday, 9 June 2022 at 15:23:35 UTC, Timon Gehr wrote:
> [snip]
>
> Sure, and it should be. But the example was this:
>
> ```d
> int* foo(scope int* s){ return s; }
> ```
>
> There is no upside to allowing this `scope` annotation.

Am I right that the reason to only issue the error in @safe code 
that the compiler can only be 100% sure that it is scope is in 
@safe code?

What about making it so that in @system code it does the checks 
the best that it can? In other words, if the compiler can verify 
that you aren't using scope properly in @system code, then it 
gives an error as if it is @safe, but if it can't verify it then 
the current behavior with -preview=in occurs (I understand some 
risk of undefined behavior).

I suppose the problem with that is that the user may not know 
when the scope suddenly stops actually checking correctly in 
@system code. The other alternative would be that scope works 
regardless of @safe/@system code and fails to compile if the 
compiler can't verify it properly. That makes it a bit harder to 
use though, which I imagine is why they didn't go that way.


More information about the Digitalmars-d mailing list