Struct should be invalid after move

[Alex]

On Tuesday, 27 November 2018 at 12:51:58 UTC, Stanislav Blinov 
wrote:
> On Tuesday, 27 November 2018 at 12:42:43 UTC, Alex wrote:
>> On Tuesday, 27 November 2018 at 12:03:20 UTC, Sebastiaan Koppe 
>> wrote:
>
>>>> auto val = Handle.init;
>>>>
>>>> 1. How do you treat this?
>>> I have no idea. Logically I would say that - in my case - the 
>>> val is invalid.
>>>
>>
>> This is a source of bugs. The T.init value is the one and only 
>> value, which exists, independently from the definition (of 
>> Handle). Therefore, your own functions on Handle have to 
>> consider this case and have to behave properly. I.e. define 
>> some behavior.
>
> No. The only thing that must be valid to do with a value in 
> .init state is destruct it.

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.

> 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.

>
>>> Sure, I could put in a runtime check, but then I get runtime 
>>> errors and I rather have compile time errors.
>>
>> 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.