Struct should be invalid after move

[Stanislav Blinov]

On Tuesday, 27 November 2018 at 15:14:13 UTC, Alex wrote:
> On Tuesday, 27 November 2018 at 14:37:40 UTC, Stanislav Blinov 
> wrote:
>> On Tuesday, 27 November 2018 at 13:17:24 UTC, Alex wrote:
>>
>> For compile-time checks, sure, as it is a convenient way to 
>> get at the underlying type. But that's all that is.
>>
>> 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.
>>
>
> Ok... so. Without default construction,
>
> int i;
> and
> int i = void;
>
> become the same. But you won't be able to prevent it from being 
> an int, right?
> How would you detect an invalid state in this case?

You wouldn't. int doesn't have an invalid state. That's not 
what's in question here. This is:

```
struct S {
     private X* ptr;
     @disable this();
     @disable this(this);
     this(X* p) { ptr = p; }
     ref get() return @safe { return *p; }
     alias get this;
}
```

...or pointers in general.

>> 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.
>
> I assume, that detecting invalid states becomes harder as types 
> become simpler.

There's no difference. If the compiler would know what an invalid 
state is and what operations result in it, it doesn't matter what 
the type is.

> And, it depends strongly on the application, whether a value is 
> considered invalid... Doesn't Typedef already allow this 
> functionality?

No, it does not. We are talking about complie-time checking, not 
runtime checking.