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