Sum Types - first draft

[Richard (Rikki) Andrew Cattermole]

On 10/09/2024 5:15 PM, Richard (Rikki) Andrew Cattermole wrote:
> 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.

The reason I have not redone my proposal for sumtypes and posted it here 
is that I'm waiting on the member-of-operator AND matching syntax. The 
first matching proposal is in the DIP queue for Walter's and Atila's review.

Without both you end up with 4, 5, 6, and 8.