Struct should be invalid after move
Stanislav Blinov
stanislav.blinov at gmail.com
Tue Nov 27 15:25:14 UTC 2018
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.
More information about the Digitalmars-d
mailing list