draft proposal for Sum Types for D

[Paul Backus]

On Monday, 5 December 2022 at 17:31:11 UTC, Jacob Shtokolov wrote:
> On Monday, 5 December 2022 at 14:50:47 UTC, Paul Backus wrote:
>> IMO if you want this kind of extensibility, a sum type is the 
>> wrong tool for the job. This is *exactly* the use case that 
>> classes are designed for: extending existing code to operate 
>> on new types, without modifying the code itself.
>>
>> Sum types, by contrast, excel when the set of types is fixed, 
>> but you would like to be able to define new operations on that 
>> set of types without changing existing code.
>
> That would be the case, but D has things like BetterC which 
> doesn't support classes (okay, it supports C++ classes, but 
> still).

If the problem is that BetterC has poor support for classes, then 
the solution should be to improve BetterC's support for classes 
(e.g., by making D classes less dependent on `TypeInfo`).

> There are other cases where one might need to extend such sum 
> types, say, you want to extend error types, etc.

The Rust community has come up with a variety of techniques to 
handle cases like this using library code. I am confident that D, 
with its powerful metaprogramming and reflection, is capable of 
handling them just as well, if not better.