Getting action on your favorite D issues

[Paul Backus]

On Saturday, 6 June 2020 at 22:01:51 UTC, Steven Schveighoffer 
wrote:
> On 6/6/20 5:38 PM, Joseph Rushton Wakeling wrote:
>> 
>> Doesn't that also apply to void-initialized values in the case 
>> that the implementation allows arbitrary bit-patterns (what 
>> IIUC the C99 standard calls trap values)?

Here's the definition of "trap representation" from the C99 
standard:

> Certain object representations need not represent a value of 
> the object type. [...] Such a representation is called a trap 
> representation.

So, for example, 0x42 is a trap representation for the type 
`bool`, because there's no value of type `bool` that corresponds 
to that pattern of bits.

> Yes, it's the same thing. This is why I specifically said that 
> the case of:
>
> int x = void;
>
> won't corrupt memory *as long as everything that uses it is 
> @safe*. This is due to the fact that all indexing operations in 
> @safe code are bounds-checked.

It's also due to the fact that the type `int` has no trap 
representations. Every bit pattern corresponds to a valid integer.

>
> As soon as you start using @trusted, then the semantic meaning 
> of what x actually represents comes into play.

As long as the @trusted code is written correctly, it's safe 
regardless. The @trusted code has to be prepared to receive every 
possible safe value [1] of type `int`. Since every value of `int` 
is safe, it must be prepared for all possible values of type 
`int`. And since `int` has no trap representations, this is the 
same as being prepared for all possible bit patterns that could 
be stored in an `int`.

> The thing we *should* do is just disallow all these corner 
> cases in @safe code. It's much easier to relax it in certain 
> cases later than it is to add on band-aids for all the bad 
> cases.

It is sufficient to forbid void-initialization of any type with 
unsafe values [1]--including trap representations.

[1] https://dlang.org/spec/function.html#safe-values