fix Issue 21665 - Void initialization should not be allowed for insta…

[WalterBright]

…nces of struct with invariant

The bug report mentions two problems - the one in the title and when a union field has a struct with an invariant. This fixes both.

The code added is very similar to the implementation and checks for hasPointers().

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21665	normal	Void initialization should not be allowed for instances of struct with invariant

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#12326"

[WalterBright]

Azure pipelines:

TF400898: An Internal Error Occurred. Activity Id: b6b8ee4a-3963-422a-9cba-86c32e333331.

whatever that means.

And buildkite's log just ends with no message.

[ghost]

can be const, and all the other hasInvariants() too. Excepted perhaps the one that may cache the information.

[WalterBright]

Won't work because of the overriding one that can't be const.

[RazvanN7]

I'm not convinced that special casing structs with invariants is the right approach. I would argue that either we make void initialization of structs invalid in @safe code altogether or we consider the code in the bug report (which by the way, does not compile currently) as correct. I mean, having the code accepted or rejected based on the existance of invariants seems arbitrary to me.

How can using a void initialized struct be @safe?

[pbackus]

Given the current spec, void initialization cannot be @safe because using a void-initialized variable always results in undefined behavior.

Void initialization could be @safe if (a) its behavior were defined as yielding an unspecified value (see dlang/dlang.org#2260), and (b) all values of the type being void-initialized were safe values.

In this case, it would make sense to take invariants into account because violating a struct invariant is explicitly specified to result in undefined behavior. It follows that any struct instance which violates its invariant must be considered an unsafe value, and therefore that struct types with invariants could not be void-initialized, accessed when overlapped in a union, etc. in @safe code.

[WalterBright]

Corresponding spec pull dlang/dlang.org#2990

[WalterBright]

void initialization is a very valuable optimization tool, especially in things like having temporary buffers allocated on the stack:

int[100] buffer = void;

We must not be hasty in throwing it under the bus. Having an undefined value is not the same thing as undefined behavior:

int i = null;
writeln(i); // prints implementation-defined value, not undefined behavior
char[] a = null;
writeln(a); // undefined behavior

A struct with an invariant implies only a subset of values of the fields should be possible. Therefore, in @safe code void initializers or overlapping unions of them should not be allowed in @safe code as it violates the invariant constraint.

[RazvanN7]

Should this go through a deprecation cycle? In theory, this has the potential to break code out there, however, one may argue that such code was broken anyway. I, personally, think we could bypass the deprecation in this case, but I'm curios what other people think.