-
-
Notifications
You must be signed in to change notification settings - Fork 662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type.typeof(Int64.make(0, 0)) yields different results between different platforms #3096
Comments
That"s by design. Some targets can use their native Int64 implementations while others have to emulate it. |
Whatever the design is, returning |
I agree. I can change that for Java/C# |
You may want to wait till the Int64 pull request is merged. |
Okay. Makes sense. |
This can (and should) be addressed now. |
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 |
I think the main point here is that Int64 can"t be distinguished from Int and Float on these targets. |
Should we add a new TInt64 result? |
@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. |
The problem right now is that people who used |
@Simn we could add a Int64.is for the time being |
(which would be not exclusive, which means an Int could be Int64 if that"s the way it"s implemented on the platform) |
What about serialization btw? |
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) |
First, I think the behavior in Java should be considered a bug, since Second, a non exclusive 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. |
I can"t see us addressing this in any clean way without adding TInt64. |
Should we add a TInt64 type? |
I think so. |
I agree. I can do Java/C#"s part, but we"ll need it to be implemented on the other targets as well |
Start a branch then! |
TInt
orTDouble
for Java targetsTClass(haxe.Int64)
for Flash targetsTClass(haxe.Int64)
for Neko targetsThe text was updated successfully, but these errors were encountered: