Rudy Ges

Ideally such a solution wouldn't get in the way when we do the `haxec` thing (at which point the compiler itself wouldn't know about such lib versions at all?)

Doesn't make sense to me to add support to `final` but don't implement it as `final`. Seems harmful if anything to me.

On `development`: ``` src/Main.hx:50: catch Error TEnum(haxe.io.Error) src/Main.hx:24: handle Error TEnum(haxe.io.Error) ``` From 4.3.0 to 4.3.7: ``` src/Main.hx:47: catch FirstErrorEnum TEnum(haxe.io.Error) src/Main.hx:18: handle FirstErrorEnum: TEnum(haxe.io.Error) ``` On Error change or...

> It's not very easy to tell with this convoluted example, but I think development output is correct. The cpp or hl one? :/

Seems to be https://github.com/HaxeFoundation/haxe/pull/10519 Will try to find what has been fixed there since then in development

Yeah but unless there's another way to repro the actual issue, before that this issue could not happen as it was wrapped in `ValueException`

Isn't that use case pretty niche? A build macro (or `addGlobalMetadata`) could do that job easily

I think this makes sense. A test would be nice, or at least a code example of what case it helps with (I could then help with writing the test...

I'm not sure. What are the rules here for deciding what documentation is included or not?

First thing that comes to mind is externs which could have "real private" impl? But if that's an issue, disabling this for externs should be an easy enough fix..