sumtypes for D

[Tejas]

On Wednesday, 30 November 2022 at 03:55:18 UTC, Paul Backus wrote:
> 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:
>>> [...]
>>
>>
>> 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.

Oh? What are these enhancements?

- One is Deadalnix's "allow `const type!int` to convert to 
`type!(const int)`"

- Another I know of is many folks asking for some kinda hook in 
the template type inference process