Implement sumtypes and matching

[rikkimax]

Will update later.

[rikkimax]

I just remembered more of the operator overloads need to be generated
Oh and is expressions is(T == __sumtype)
Could probably avoid some like toHash and just change runtime code for it.

[LightBender]

I understand that this is a massive pull request, but sumtypes/matching is a big new feature, and one we need to keep up with even stodgy old conservative languages like C#. If we can pile into this and get multiple people to review it should be manageable.

@WalterBright @tgehr

[rikkimax]

For reference, this design reduces to lowering to structs (literals + declarations), and ternary expressions (match).
It's fairly straightforward and is a pretty self-contained add-on in comparison to how it could've been done.

Overall I'm very impressed with the code quality MiMo V2.5 came up with, I couldn't have done it better (overall).

[Herringway]

I don't see what the point is. The syntax isn't an improvement over the library solution, and I don't see any new functionality being offered. Is all this just to save an import?

[rikkimax]

Match expression support guard expressions and there are both named and unnamed variants.

[Herringway]

Match expression support guard expressions and there are both named and unnamed variants.

The latter can be supported in the library solution. The former just looks awkward and inconsistent with the rest of the language. Why does this need a fancy new syntax that we can't use anywhere else?

[rikkimax]

If you want to extend match expressions to other types that is fine. But I am not working on that right now, and the scope is sufficiently large.

Just because something can be done in library does not mean that it is the correct place to put it.
See fullyQualifiedName and bitfields as a good example of something that should never have existed.

Sumtypes are a primitive of data representation, same as tuples. Much more so than a map or a dynamic array.
The fact is, D is not keeping up with the mainstream understanding (which is lagging by a good 40 years of the literature).

[rikkimax]

Oh and another thing, match functions can't actually be safe if the argument is by-ref.
Its not possible to throw static analysis to sufficiently guarantee it either.

The match expressions, due to not using function calls can be analyzed with a borrow checker, and therefore the variables can be by-ref. Which is a pretty massive upgrade.

[Herringway]

Just because something can be done in library does not mean that it is the correct place to put it. See fullyQualifiedName and bitfields as a good example of something that should never have existed.

It doesn't mean that it isn't the correct place to put it, either. And bitfields are far better than the C garbage that's supposedly replacing them. I used to think D's greatest strength was its metaprogramming, but it's doomed to be deficient, isn't it?

[rikkimax]

And bitfields are far better than the C garbage that's supposedly replacing them.

Which can be fixed with a simple linting rule, which I implemented but wasn't accepted.

I used to think D's greatest strength was its metaprogramming, but it's doomed to be deficient, isn't it?

Yes, but not because of the design or implementation of metaprogramming stuff.
Templates themselves are designed and implemented fairly well; I haven't found anything I really want to change about it.
Some more traits to extract information would be helpful.

The core problem is overall compiler architecture wasn't designed to solve cyclicity in analysis, which prevents effects analysis, and the behaviour isn't correct. On the flip side, you get fast compile times, so it isn't all bad.

[github-actions]

DMD perf check

Metric	Base	PR	delta
compile hello.d (instr)	215.5 M	225.6 M	+4.67%
compile hello.d -O (instr)	234.0 M	244.1 M	+4.30%
compile Phobos (instr)	5,125.4 M	5,156.5 M	+0.61%
compile Phobos codegen (instr)	1,473.1 M	1,472.5 M	-0.04%
compile vibe.d (instr)	15,120.5 M	15,157.7 M	+0.25%
dmd binary size (stripped)	6.90 MB	6.82 MB	-1.18%
hello binary size	0.72 MB	0.72 MB	0.00%
peak RSS (compile hello.d)	44 MB	43 MB	-0.15%
peak RSS (compile Phobos)	636 MB	640 MB	+0.52%
peak RSS (compile vibe.d)	1981 MB	1981 MB	-0.03%