Nicolas Cannasse

This might break some runtime wrt Array handlings, we need proper unit testing for Haxe 4.0, we will discuss if we can make java/c# compliant in time but we need...

This is not so easy. I think I kept it because there's several cases where the type needs to be cast, especially when dealing with interfaces, structures, or polymorphic arrays.

I don't like much `asyncio` as toplevel package. I thought we would be using `asys` toplevel package that would somewhat mimic the `sys` one but with async variants and upgraded...

Let's document what's in std, without political considerations please :)

Yes I'm aware of the issue with Bytes redefinition. I actually opened https://github.com/HaxeFoundation/haxe/issues/4249 because of that. Not sure if that's the right solution or not. I actually thing we need...

This currently breaks haxe.io.BytesBuffer compilation, and breaks some WebGL code I'm having in Node Webkit as well (since I need to have Bytes that maps to JS ArrayBuffer). Should we...

Up again : should we remove this and instead add NodeBuffer Bytes conversion (in NodeBuffer class) since they are both based on ArrayBuffer but uses different APIs ?

Maybe, but that just moves the problem away, no ? I think it would be nice for Haxe users to have a crossplatform sys API for Node. Even more if...

Oh. then that makes things easy, right ?

What I'm proposing (open for discuss): - support 4.0+ Buffer (which extends UInt8Array) - do not redefine haxe.io.Bytes and especially not BytesData (breaks several std classes and 3rd party libraries)...