Re: What is the case against a struct post-blit default constructor?

[Steven Schveighoffer]

On Thu, 11 Oct 2012 13:23:10 -0400, Jonathan M Davis <jmdavisp...@gmx.com>  
wrote:

Any situation where the init value is essentially invalid (like it would  
be
with floating point types) makes it so that you can't have an invariant,  
and in
many of those cases, having a default constructor which was always called
would solve the problem. I'm still in favor of _not_ trying to add  
default
constructors given all of the issues involved, and I agree that on the  
whole,
init is a superior solution (even if it isn't perfect), but there _are_  
cases
where you can't have an invariant because of it.


Isn't it possible to customize when an "invariant" is called using  
contracts?

For example:

struct S
{
   private bool isValid;
   private void _invariant() {assert(isValid);}

   void foo()
   in { _invariant();} out {_invariant();} body
   {
      // whatever
   }

   void opAssign(ref S other)
   out {_invariant();} body
   {
      isValid = other.isValid;
   }
}

???

Yeah, It's extra work.  But essentially, isn't this what you want?  The  
thing about disabling invariant checks on some specific function in some  
specific case is that someone else has a valid case for requiring it.

The only sucky part about the above is, _invariant is compiled in even in  
release mode (though it should inline to a noop).

-Steve