[ntrel]

Why is your proposal better than this:

  import std.sumtype;
  
  void main(){
   struct A { int a; }
   struct B { string b; }
   struct C { bool c; }
   
   alias TaggedUnion = SumType!(A, B, C);
   
   auto tgu = TaggedUnion(B("hi"));
   int i = tgu.match!(
    (A a) => a.a,
    (B b) => b.b.length,
    (C c) => c.c * 5
   );
   assert(i == 2);
  }

If you miss out a `match` handler for any of A, B, C you get a compile-time error. Or you can use a generic handler which will be instantiated for any type not explicitly handled. https://dlang.org/phobos/std_sumtype.html

[Shadonototra]

I'd take a language that have built in support for tagged union over having to import a module and rely on templates

I know of sumtype, and i think it is a mistake for D to rely on this for such important language feature

I'm not a language dev, so i can't do much to help, using switch/union/enum is more natural, is cleaner, and is easier to add support for IDEs, everyone on the same page

That's in areas like this where the language falls short, and i can see people instead choosing alternatives

https://github.com/dlang/phobos/blob/master/std/sumtype.d

a mess of templates and imports to std.traits

using this will make your compile speed tank.. another reason to avoid

it's very sad that people recommend this instead of asking for built-in version, makes me sometimes reconsider my choice to use the language

if they expect language improvements to be templates, what atrocity will be added next?

this is on the same level as std::bool from C++

[Shadonototra]

https://forum.dlang.org/post/[e-mail]...

> The good news is, I have not put a lot of effort so far into micro-optimizing the compile-time performance of match, so there is almost certainly room for improvement.

it is shame that it ended up in the standard library

once Walter will be gone, i will have no faith in the language anymore

[germandiago]

bool is a built-in type in C++...