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