On Tuesday, 10 July 2018 at 00:01:28 UTC, Steven Schveighoffer
wrote:
On 7/7/18 11:06 PM, FeepingCreature wrote:
On Friday, 6 July 2018 at 23:37:30 UTC, Simen Kjærås wrote:
As for alignment, GC, and possibly other things, the code was
not intended as a complete implementation of Nullable, only
to show that an actual member of type T is not necessary.
These issues are fixable, if perhaps nontrivial in some cases.
--
Yeah, sorry - that was a snap answer; union is indeed not a
solution, particularly since it doesn't even work for types
with elaborate destructors.
That said, I agree that this can be implemented, however imo
the fact that we have to retrace the work of the compiler in
laying out the data is a warning sign - imo, it happens
because what we actually want is for the compiler to *work a
different way*, which is why we find ourselves painstakingly
recreating its interna in userland, except with different
destructor semantics. This points at a flaw in the language,
imo - if we so urgently need a way to express different
semantics, we shouldn't have to painstakingly hide the type
behind the compiler's back; the compiler should have our back
in this instead of fighting us.
Hm... this reminds me of the recent discussion around
__symbols, and how they are treated specially.
Could we reserve some subset of those symbols to say "treat
these differently"?
Or have an attribute that marks a member in such a way? I'm
reminded of of the future storage class __mutable as well.
-Steve
That would also solve the problem.
Note that I've recently realized that the format!""
weird-exception bug ( issue 19003
https://issues.dlang.org/show_bug.cgi?id=19003 ) is based on the
same root assumption - Phobos blithely presumes that T.init is a
valid instance of T that it can, say, call toString() on.
Do you think "Structs with nontrivial Domain Data Considered
Harmful" would make a good article name?