Blogpost about the T.init problem

FeepingCreature feepingcreature at gmail.com
Wed Jul 11 07:35:24 UTC 2018


On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
> Then just stick it in a Nullable. No explicit .init needed.

To clarify this point some more, since on reflection it's 
ambiguous: you might well say that "well yeah, the default 
constructor returns an invalid value, no shit it breaks." The 
semantics of Nullable are weird here though - Nullable!S 
constructs an S while pretending to not contain an S. The deeper 
problem is that there is straight up *no way* to implement 
Nullable correctly in a way that lets it handle types with 
@disabled this(); without using pointers there's no way to bypass 
S's destructor, and any implementation of Nullable that uses 
T.init explicitly dies when D tries to destruct it.

> That would work, it's just a really horrible hack and I hate 
> it. We're constructing a fictitious domain value that passes 
> our invariants while having zero correspondence to the real 
> world, *just to pass our invariants*. It's an obvious sign of a 
> language issue.

Furthermore, note that this limits the amount of invariants we 
can define. For instance, we can't define an invariant that says 
that a value has to be registered in a central table somewhere - 
since our fictional value obviously won't be. Better to do bool 
isInitialized = false, and that's already crappy.


More information about the Digitalmars-d-announce mailing list