Holes in structs and opEquals

[yigal chripun]

Walter Bright Wrote:

> yigal chripun wrote:
> > The compiler knows at compile-time what variables are initialized with "=void". The compiler than can add a compilation error when such a struct variable is used in an equals expression. 
> > this doesn't cover use of malloc() which must be the user's responsebility. 
> > 
> > e.g.
> >  S s1=void,s2=void;
> >  s1.s=0; s1.d=0;
> >  s2.s=0; s2.d=0;
> >  assert(s1 == s2); // <- this line should not compile
> > 
> 
> 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.
> 
> 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.

Ok, that sound's reasonable if you want to keep the compiler simple and fast.
How about same mode though? maybe it's worth to add this check only as part of same mode, where there are less cases anyway since malloc() isn't safe, and there are no pointers. is it allowed to use "=void" in safe mode at all?

another question I have: How would a user initialize the holes and doesn't it negate the bebefits of void as optimisation?