sumtypes for D

[Paul Backus]

On Wednesday, 30 November 2022 at 05:29:03 UTC, Tejas wrote:
> On Wednesday, 30 November 2022 at 03:55:18 UTC, Paul Backus 
> wrote:
>> 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

Stuff like

- User-defined implicit conversions.
- Returning error messages from failed `is(...)` and 
`__traits(compiles)` checks instead of just `false`.
- Allowing library code to *display* its own custom error 
messages, with the same control and flexibility the compiler has 
for built-in messages (currently we only have `static assert`).
- User-defined GC scanning for library types (`opGCScan`?).
- User-defined value ranges for aggregate fields (e.g., pointer 
that can't be null, integer that can't go above/below a certain 
limit).

All of these are things that built-in types have access to 
already, and all of these would have useful applications beyond 
just sum types.