-
-
Notifications
You must be signed in to change notification settings - Fork 299
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
Use int64 rather than int for public integers #1731
Comments
I've been chipping away at a change to resolve this issue. It is proving to be quite intrusive. Consider something like the implementation of the
All functions of this sort need to be changed to use an explicit Note that unit tests which do something like |
My main concern is not whether this change should be done. The external behavior of Elvish on 32 and 64 bit platforms should be identical. The question is how to minimize the size of the necessary changes, possibly by breaking them up over several commits. |
The user
To which I replied:
Note that this works on 64 bit platforms but not 32 bit platforms:
But not 32 bit platforms:
I can't see a good reason why the modulo command should behave differently based on whether the platform uses 32 or 64 bit integers. |
Ideally, the use of
Now, it's possible that it's much easier to extend some functions in class 2 to accept |
Indeed, that is the source of much of the difficulty I've encountered in trying to switch from I tabled working on my original approach a couple of months ago. In the hope that revisiting the code after putting it on the shelf for a few weeks would yield insights on how to simplify the change. But that seems unlikely after taking another look at my work-in-progress.
My current work-in-progress surfaced only a handful of cases where that is true. It looks like it is easier to modify those cases to explicitly convert |
There was a recent thread opened by someone who was surprised that
randint
failed with a "cannot parse as integer" exception. It turned out they were using a 32-bit version of Elvish. A 64-bit version of Elvish handled the situation. It seems to me that Elvish should uniformly use int64 in its public APIs (e.g., therandint
command) where that is possible. That an int64 may be slower than an int on 32-bit platforms is less important than consistent behavior by Elvish on platforms with different native integer width.The specific example was this:
randint 100000000000 1000000000000000
. But there are plenty of other builtins that useint
whereint64
is preferable. Maximal speed on 32-bit platforms is less important than consistent behavior on platforms with 32 and 64 bit word length.The text was updated successfully, but these errors were encountered: