Andreas Rumpf

In my unwritten proposal I used this syntax: ```nim type Tree = ref case kind # also possible without the `ref` of StringLeaf: str: string of IntLeaf: x: int of...

> eg. you don't really need the labels str, x, kids in your Tree implementation, just the types That's a good point but easily fixed: ```nim type Tree = ref...

I care about keeping the `of` branches, if you want to change `case` to `sumtype` or `union` I don't mind it. Though both `sumtype` and `union` are ugly. Maybe `enum`?...

```nim type Tree = nested enum StringLeaf: string IntLeaf: int Parent: seq[Tree] ``` is wrong for two reasons: You need the `ref` indirection in order to nest it. And `StringLeaf:...

> I think that'd kind of lead people in the wrong direction wrt. pattern matching. Actually, this is how you ensure correctness, having thought about it, you handle every case...

> possibly even exhaustiveness checking Nim's `case` statement already does exhaustiveness checking and I have no intention of moving to something that lacks it.

It's not "brittle", it works as intended. I'm also not familiar with any mainstream language that offers exhaustiveness checking over nested `case`/`match` statements in the way that you outline.

Please make it happen.

I still don't get the fixation on the inline assembler when not even "hello world" works with NIR. Priorities from outer space, sorry.

The allocator in 2.0 did change to use a shared heap and I think this change is only in the 1.9-2.0 line but cannot remember for sure. > or are...