Skip to content
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

CalcIntType -> long, because int might lead to loss of data… #63

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

ams-tschoening
Copy link
Contributor

@ams-tschoening ams-tschoening commented Jan 27, 2017

@ams-tschoening ams-tschoening changed the title CalcIntType -> long, because int might lead to loss of data in some c… CalcIntType -> long, because int might lead to loss of data… Jan 27, 2017
tschoening and others added 7 commits January 27, 2017 20:34
… lietral is provided. which should be a regular use case. Long.valueOf(...) shoudl have been optimized in that case for low indices as well, but this way we don't need to care and don't add extra source to the result.
…ts is created: new ArrayList<Long>(Arrays.asList(0, 1, 100500)) doIntLiteral doesn't know that a Long is required and the va.lues itself don't require one,. so doIntLiteral keeps providing the numeric literals without "L" suffix, which results in "int"s by default in Java and an array of int can't be casted to a required array of long.
@GreyCat
Copy link
Member

GreyCat commented Apr 8, 2019

Actually, I wanted to return to this topic. I'll try to check if we can make that transition with the tests and hopefully we'll do it. Current "default is 32-bit int" indeed makes things much more complicated than it could be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants