Struct should be invalid after move

[Stanislav Blinov]

On Tuesday, 27 November 2018 at 13:17:24 UTC, Alex wrote:

> I have something completely different in mind...
> std.traits is full of examples, where T.init is used beyond of 
> destruction.
> And the behavior of a function for a .init value is also 
> defined at all times. Independently from how the function is 
> written. It can be easily tested by plugging the .init value as 
> the input parameter.

For compile-time checks, sure, as it is a convenient way to get 
at the underlying type. But that's all that is.

>> Standard library move et al. assume as much. In fact, what 
>> they do is exactly that - wipe out the moved from value, 
>> emplacing the initializer there. What also *may* be valid is 
>> reinitialization/assignment.
>
> Sure. And I don't question this. I just would like to know, how 
> the custom functions of OP handle the case of .init.
> I mean... If they don't, then they assume the value is not in 
> the .init state and perform some actions with it, which can 
> lead to some assert. Which would be perfectly ok.

Right now we have to resort to runtime checks. Which is hilarious 
considering we *can* disable default construction, thereby 
asserting that .init is indeed an invalid state.

>>> This is not an answer to my question. The question was: why 
>>> you would like to have a different behavior w.r.t. some other 
>>> behavior, which exists, independent of your actions.
>>
>> Because .init does not generally exert any useful behavior.
>
> Hmm... sure. But some behavior exists. And my question is: why 
> (not even how) the behavior should differ between the .init 
> case and the case after a move.

What Sebastiaan proposes is for there to be *no* behavior at all, 
as using an invalid value would become a compile-time error. 
Which would mean one wouldn't need extraneous run-time checks.