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 <jmdavisProg at 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