Type based enums

[ncannasse]

We discussed on slack an alternative approach using union types + case x is T: pattern matching with exhaustiveness check. This would be closer to actual runtime implementation.

[AdrianV]

if ClassA and ClassB share a common root, than the test must be in order from the most "outer" class down to the class which is nearer to the common root. In your example if ClassB extends ClassA the pseudo code will fail, because v is ClassA will hold for both.

[back2dos]

This seems like the text book edge case for @:genericBuild macros. Also you could generate something that's the best of both worlds:

abstract AorB(Dynamic) from ClassA from ClassB {
    public inline function match(fa:(a:ClassA)->Void, fb:(b:ClassB)->Void)
      if (this is ClassA) fa(this) else fb(this);
}

The resulting code looks near optimal: https://try.haxe.org/#6F070b03

In the follow up comment, there are two noteworthy ideas:

1. union types
2. type matching

But I guess both would have to be fleshed out considerably, if that's something we're considering (and I'm not sure that we are, because it has been rejected here in a number of variations).

[Simn]

I'll close this because we decided to do something else anyway.

I'm not opposed to union types (anymore). While I still think that they cause bad code, who am I to stop anyone from writing bad code... I acknowledge that union types can be very useful for interfacing with externs, and they might even come in handy for the coroutine implementation.