Holes in structs and opEquals

[bearophile]

Walter Bright:
> It can, but I don't agree that it should. For an =void initialization, 
> it's the user's responsibility to initialize it properly. The use of 
> =void implies the user knows what he's doing with it, and will take care 
> to initialize the 'holes' as necessary.

I don't fully like this design strategy, I don't like to separate so much the safe code from the unsafe code where the compiler refuses to give any safety. A good compiler has to help assure safety every time it can.

On the other hand I agree with you that your design strategy helps keep the compiler simpler (and sometimes compilation time low), and I agree that there are times where it's hopeless to try to turn something unsafe in something a little safer. It's a waste of time that can be used for something more useful. So in the end I shut up the muzzle :-)


> Trying to disable == for such structs is a losing battle, anyway, as the 
> compiler could only detect the most obvious cases. Pass a reference to 
> it to a function, store it in a data structure, etc., and all that goes 
> away.

In theory a lint for D code can partially trace such movements to spot such troubles (in debug release it can even add to the void structs an extra bool attribute that always gets initialized, to tell apart initialized from uninitialized structs at runtime and spot such bugs, but this starts to sound a little silly).

Bye,
bearophile