Getting action on your favorite D issues

[Steven Schveighoffer]

On 6/6/20 8:33 PM, Paul Backus wrote:
> As long as the @trusted code is written correctly, it's safe regardless.

Consider an integer which represents the length of an array. Instead of 
the full bit pattern of the integer being valid, only the bit pattern 
that is less than or equal to the memory size is valid. And this is not 
something that can be checked even at runtime -- @trusted code must 
depend on the value being correct. This is enforced for D's builtin 
arrays, but not for a custom array type.

And currently there's no way to convey that danger to the compiler. 
Especially where unions and void initializations are involved, there are 
ways to use @safe code to subvert @trusted code, even for private 
variables. Even with careful encapsulation, D has ways to get at the data.

This is especially a problem with types which have a semantic invariant 
between calls to its members.

-Steve