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