Type.typeof(Int64.make(0, 0)) yields different results between different platforms

[Atry]

• TInt or TDouble for Java targets
• TClass(haxe.Int64) for Flash targets
• TClass(haxe.Int64) for Neko targets

[Simn]

That's by design. Some targets can use their native Int64 implementations while others have to emulate it.

[Atry]

Whatever the design is, returning TInt or TDouble for a Int64 makes no sense.

[waneck]

I agree. I can change that for Java/C#

[Simn]

You may want to wait till the Int64 pull request is merged.

[waneck]

Okay. Makes sense.

[Simn]

This can (and should) be addressed now.

[ncannasse]

Reflection on abstracts is problematic.

We could add a new TInt64 result, but are we sure we can correctly deduce it on all platforms ? (no false positive, and no missed value) + this will require additional things in (Un)Serializer

[Simn]

I think the main point here is that Int64 can't be distinguished from Int and Float on these targets.

[waneck]

Should we add a new TInt64 result?

[ncannasse]

@waneck I think that's a bit early for that, same for supporting Int64 in serializer. Let's way a bit more until it becomes a first class citizen.

[Simn]

The problem right now is that people who used Std.is(v, Int64) do not have an alternative.

[ncannasse]

@Simn we could add a Int64.is for the time being

[ncannasse]

(which would be not exclusive, which means an Int could be Int64 if that's the way it's implemented on the platform)

[Simn]

What about serialization btw?

[ncannasse]

Same, I think we should wait for 3.3 to fully support Int64 in terms of reflection/serialization, if it needs to be (which i'm not yet sure)

[jonasmalacofilho]

First, I think the behavior in Java should be considered a bug, since Type.typeof will return TFloat for values that can't be represented at all with a double. Even if no more Int64 changes are pushed to other targets, fixing this in 3.2 would be awesome.

Second, a non exclusive Int64.is if fine. Or, how about adding TInt64 to ValueType, as proposed on IRC by Simn?

Finally, the point of the recent changes hasn't been to improve the usage Int64? This suggests that it should be a first class citizen in Haxe, thus supported for reflection/serialization as soon as possible.

[Simn]

I can't see us addressing this in any clean way without adding TInt64.

[waneck]

Should we add a TInt64 type?

[Simn]

I think so.

[waneck]

I agree. I can do Java/C#'s part, but we'll need it to be implemented on the other targets as well

[Simn]

Start a branch then!