draft proposal for Sum Types for D

[ryuukk_]

On Monday, 5 December 2022 at 18:41:39 UTC, Paul Backus wrote:
> 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.

Zig and Go does it better, they don't need any "library" 
"reflection" "metaprogramming", i would never use a language that 
needs a library to work with errors, it's tasteless