Sum Types - first draft
Richard (Rikki) Andrew Cattermole
richard at cattermole.co.nz
Tue Sep 10 05:15:30 UTC 2024
I'll ignore the formatting issues with the headings.
1. While it is a little like an enum, it is only the tag that is the
enum, not the elements.
2. Use a hash of the tag name + tag type, this allows it to combine
between instances by copy alone. This was suggested by Jacob Carlborg
for my design ages ago and it is brilliant.
3. Sumtypes need to support copy constructors, postblits and
destructors. Otherwise you limit their usability too significantly. This
requires a variable size virtual table that goes along with it.
4. Null does not need special casing, either ``typeof(null)`` is in the
element set or its not.
5. Do not use this ? syntax for determining what the tag type is. That
will prevent us doing the nullability operators which people including
myself want. Matching takes over on this, it is not needed.
6. For reading, I would recommend against doing it in ``@safe`` code. If
you want it to be safe, use matching.
7. There is no alternative syntax proposed, there are two different
syntaxes with different tradeoffs, with one have significantly more
familiarity to people who have been using sumtypes for 50 years. Both
need to exist.
8. While it appears to be a good idea to place the tag name using a
single identifier syntax, it keeps it nice and simple after all, it does
require that a tagged union has to give each and every element a name.
Note all existing D implementation of sumtypes do not have this
requirement, it is too restrictive and does not match the communities
understanding of the concept. Use my member-of-operator syntax for
providing this functionality. It was due to be up next... but I'm
working on escape set.
More information about the dip.development
mailing list