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

[Jonathan M Davis]

On Friday, October 12, 2012 11:49:48 David Nadlinger wrote:
> On Friday, 12 October 2012 at 09:42:19 UTC, Jonathan M Davis
> 
> wrote:
> > That sounds like a decent solution to me, but I think that
> > there's a good
> > chance that Walter would reject it on principle (since in
> > general, skipping
> > the invariant pretty much defeats the purpose of having one).
> 
> But he already suggested implementing a _custom_ mechanism for
> skipping the invariant somewhere else in this thread (i.e. a
> "valid" flag) which is arguably even worse…

Clearly, I missed that. But that's definitely not particularly clean (though it 
_can_ be done right now without making any changes to the language, which for 
most things is the better approach). It's not as bad now that with have 
version(assert), since it makes it so that the valid flag can be compiled out 
in release mode, but it's still messier than @noinvariant would be (if nothing 
else, it requires more code and a version(assert) block every time that the 
valid flag is used), and more importantly, it only solves the T.init case and 
not the case where the struct is initialized to void. So, @noinvariant makes a 
lot more sense, but it _does_ require an update the language, so I wouldn't 
expect Walter to be all that enthused about it, but if he already thinks that 
a "valid" flag is okay, then he wouldn't necessarily be opposed to the idea of 
it being possible to explicitly skip invariant checks in some cases.

- Jonathan M Davis