Simon Krajewski

Your example gives me a proper error locally though: ``` Uncaught exception: Access violation Called from _Main.$Main_Fields_.main(Main.hx:4) Called from .init(?:1) ``` Do you also get that segfault locally with recent...

Yeah okay, I can't merge this before this is improved somehow because we would be going from working code to a segfault, which isn't the best upgrading experience...

I'll tell you how I got here: * There's an awful HL-specific hack in haxe.ds.EnumValueMap that was introduced [with this commit](https://github.com/HaxeFoundation/haxe/commit/7dc9272865afe5f4e1b5347da75c6d2700c67c99). * The reason that was done is because `Type.enumParameters`...

> This can't be done in some kind of bytecode verification phase either because the native `array` type does not carry type information at compile time. Meh, I expected arrays...

I agree it should work for normal use-cases. The problem is that currently assigning `Vector` to `Vector` is just fine because HL's Vector is based on Array, and our type...

I'm quite willing to merge this now unless somebody objects. This is going to cause some friction but to be fair Vector should never have been based on Array in...

`Vector.toData` returns the underlying type of `Vector`, which used to be `Array` but is now `NativeArray`. This has to be fixed in heaps, and also means that `Float32Array` is currently...

Dealing with heaps is usually bad for my blood pressure but I can take a look if I have to... And yes, good idea on the pre-alloc I suppose.

Well, I made some wrong assumptions here. I thought that Array would be based on NativeArray and NativeArray would be based on Bytes, but it's actually the case that Array...

Thank you! For me this is good now. I'll let you handle the merging so that you can synchronize with the heaps change.