Simon Krajewski
Simon Krajewski
I wouldn't generate externs for this target, it's a step that should be unnecessary, and it shouldn't even be faster because parsing text files is generally slower than reading binaries....
It shouldn't be particularly difficult because all you need after translating the data to Haxe structures is a printer.
Regarding default null-safety, I don't know yet. It might become a thing like DCE that is enabled by default for user-code. But at the end of the day, the problem...
I never used it much, but from my understanding it makes native interop a mess. Maybe @klabz has some insight, he's the expert on Haxe/C# annoyances.
Is this still relevant?
As I've said on Slack this isn't the right fix, and the problem suggests that there's something wrong with the exception management.
I think this is a decent change, but I worry that it fixes the issue only incidentally... Either way I'm fine with going ahead with this.
We should definitely disallow defining types into existing modules for Haxe 5, if we didn't do that yet.
Using structural equality is almost certainly not correct here. We never want to do this for `Type.t` because that might end up comparing `tclass` and other terrible things, which can...