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
