sumtypes for D

[ryuukk_]

On Wednesday, 30 November 2022 at 00:17:04 UTC, ryuukk_ wrote:
> On Tuesday, 29 November 2022 at 23:56:40 UTC, Vladimir 
> Panteleev wrote:
>> On Monday, 28 November 2022 at 09:27:11 UTC, Walter Bright 
>> wrote:
>>> I've written most of a DIP for one. Should I:
>>
>> I really wish that instead of adding more language features, 
>> we would improve the language so that things like this are 
>> implementable *in* the language.
>>
>> I'm not sure about the argument that not everyone might use 
>> the same type if it's implemented as a custom type. Even if 
>> one were to argue that not everyone uses Phobos, the 
>> implementation can go into Druntime, which is an extension of 
>> the compiler, which solves this problem.
>>
>> The example in the DIP about null pointers is wrong. It can 
>> still be useful to distinguish between non-null pointers, null 
>> pointers, and some third state such as "no pointer". 
>> `Nullable!(Nullable!(Nullable!int)) foo` is perfectly valid.
>>
>> We don't even need a standardized `NonNull` type or trait or 
>> whatever. Leverage existing D features instead:
>>
>> ```d
>> template nullIsValid(T)
>> {
>>     static if (is(T == struct))
>>         enum nullIsValid = {
>>             try
>>             {
>>                 union U
>>                 {
>>                     ubyte[T.sizeof] bytes = 0;
>>                     T t;
>>                 }
>>                 U u;
>>                 assert(u.t); // call invariant
>>                 return true; // no exception was thrown - null 
>> is a valid state
>>             }
>>             catch (Throwable e)
>>                 return false; // exception was thrown - null 
>> is an INVALID state
>>         }();
>>     else
>>         enum nullIsValid = true;
>> }
>> ```
>>
>> or something like that. Currently it doesn't work because you 
>> can't call struct invariants directly, and can't catch 
>> `assert(false)` in CTFE. But, these are fixable and examples 
>> of things that would improve metaprogramming at a fundamental, 
>> building-block level and enable building more cool high-level 
>> types and data structures, not just sum types.
>
> Why have slices as builtin, it should be a template that nobody 
> can read or write themselves
>
> On top of an exception hidden within..

I don't think having a language for compiler writers is 
compelling for non-compiler writers

There is value in having common constructs implemented as first 
class language feature

- better error message
- better debugging
- easier to integrate with tooling
- everyone agree on a syntax
- performance

When all the std eats the budget of template soup, what's left 
for me? using templates on top of templates on top of other 
templates, then users complain it takes 60 seconds to compile

It's important to showcase metaprogramming capabilities, but not 
everything has to be a template, specially for something as basic 
as tagged union