• yigal chripun <yigal100 gmail.com> Mar 08 2010
• Walter Bright <newshound1 digitalmars.com> Mar 08 2010

yigal chripun <yigal100 gmail.com> writes:

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? 

Walter Bright <newshound1 digitalmars.com> writes:

yigal chripun wrote:
 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.


The non-trivial cases are not detectable (halting problem), so it is a 
pointless feature to add.


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


The point of =void is to allow the user to determine those tradeoffs 
rather than the compiler.