sumtypes for D

[Paul Backus]

On Wednesday, 30 November 2022 at 03:45:13 UTC, Tejas wrote:
> On Wednesday, 30 November 2022 at 02:49:44 UTC, H. S. Teoh 
> wrote:
>> On Wed, Nov 30, 2022 at 02:23:20AM +0000, zjh via 
>> Digitalmars-d wrote:
>>> [...]
>> [...]
>>
>> By extending the language in such a way that a user type can 
>> accomplish what currently can only be done by a built-in type.
>>
>> [...]
>
>
> In the end, it will come down to allowing the programmer to 
> manipulate the AST directly in order to perform all the 
> operations that the compiler can perform... And we know AST 
> macros ain't happening
>
> # 😢

Lack of AST macros means we can't implement custom *syntax* in 
library code (except via string mixins). It does not, in 
principle, place any hard limit on the *semantics* we can 
implement.

Fully-featured pattern matching requires new syntax, so it will 
have to be a built-in language feature, but sum types themselves 
are mostly about semantics, not syntax. With a handful of 
general-purpose language enhancements, we could in principle have 
a library sumtype that works just as well as a built-in one from 
a semantic perspective--*and* we could use the same enhancements 
to improve other library-defined types, like containers, ranges, 
etc.