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

[monarch_dodra]

On Friday, 12 October 2012 at 07:36:37 UTC, Jonathan M Davis 
wrote:
> On Friday, October 12, 2012 07:53:09 monarch_dodra wrote:
>> Yes, as answered, opAssign may do things to this, such as
>> dealocate a payload, reduce a ref counter, or who knows what.
>
> A valid point, but it would be easy to explicitly call the 
> invariant at the
> beginning of opAssign if wanted to ensure that the object's 
> state was valid at
> the beginning of opAssign. You can't _not_ call the invariant 
> though if the
> compiler already does. And there's another problem which your 
> suggest against
> init suggestion wouldn't fix. It's initializing to void:
>
> S s = void;
>
> If you ever want to do that, you can't have an invariant, or 
> it'll blow up
> when you try and assign to it. And since it certainly wouldn't 
> be the same as
> the init property, checking against the init property wouldn't 
> help you any.
>
> - Jonathan M Davis

Well, again, you'd need your s to be in a valid state to assign 
to it, so I'd *hope* the invariant blew up in my face.

When you declare s void, you are supposed to memcpy .init over it 
manually, or call emplace (which does the same thing + more).

And you CAN have an invariant:

//----
import std.conv;
import std.c.string;

struct S
{
     invariant()
     {
         assert(0);
     }
}

void main()
{
     S s = void;

     static auto foo = S.init;
     memcpy(&s, &foo, S.sizeof);
     //or
     emplace(&s);
}
//----

TA-DA!!!