numeric types #2

New Issue

hartytp · 2021-01-19T20:18:54+08:00

hartytp commented

2021-01-19 20:18:54 +08:00

Constant integers are treated as int32 by default. If the value cannot be stored in int32, uint64 would be used if the integer is non-negative, and int64 would be used it the integer is negative.

Is that a good idea? Concretely I'm thinking of things like a function breaking if a constant is set too high (since now we can't add int32 and int64). I can imagine that breakage being quite non-obvious to new users.

> Constant integers are treated as int32 by default. If the value cannot be stored in int32, uint64 would be used if the integer is non-negative, and int64 would be used it the integer is negative. Is that a good idea? Concretely I'm thinking of things like a function breaking if a constant is set too high (since now we can't add int32 and int64). I can imagine that breakage being quite non-obvious to new users.

pca006132 commented

2021-01-19 21:36:49 +08:00

For writing functions, one can use a type variable over numerical types to allow users to use int32/int64/float. One problem is casting constants within the function to the type that the type variable denotes, but I think we can add special rules if needed to solve this problem (for example, let x be the type variable, maybe we can allow something like x(123) to cast 123 into int32/int64/float).

For the users, I cannot think of a good way to avoid confusion in this case. Maybe we can prohibit the user to use anything not in the range of int32, except when they wrap it in something like int64(......)? This makes it explicit.

For writing functions, one can use a type variable over numerical types to allow users to use int32/int64/float. One problem is casting constants within the function to the type that the type variable denotes, but I think we can add special rules if needed to solve this problem (for example, let `x` be the type variable, maybe we can allow something like `x(123)` to cast 123 into `int32/int64/float`). For the users, I cannot think of a good way to avoid confusion in this case. Maybe we can prohibit the user to use anything not in the range of `int32`, except when they wrap it in something like `int64(......)`? This makes it explicit.

hartytp commented

2021-01-19 21:43:23 +08:00

What does rust do for default numeric types?

pca006132 commented

2021-01-19 22:16:37 +08:00

What does rust do for default numeric types?

error: literal out of range for `i32`
 --> src/main.rs:2:20
  |
2 |     println!("{}", 12345678912345678 - 123);
  |                    ^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(overflowing_literals)]` on by default
  = note: the literal `12345678912345678` does not fit into the type `i32` whose range is `-2147483648..=2147483647`

I think it would require suffix for i64.

> What does rust do for default numeric types? ``` error: literal out of range for `i32` --> src/main.rs:2:20 | 2 | println!("{}", 12345678912345678 - 123); | ^^^^^^^^^^^^^^^^^ | = note: `#[deny(overflowing_literals)]` on by default = note: the literal `12345678912345678` does not fit into the type `i32` whose range is `-2147483648..=2147483647` ``` I think it would require suffix for `i64`.

dhslichter commented

2021-02-17 04:08:37 +08:00

I would recommend that overflows from int32 or uint32 be treated as such, and not turned subtly into in64 or uint64. For one thing, some algorithms make use of overflows as a feature. Also, then you don't have issues with a variable having been changed subtly to some other type (say int64), and then being used later as an argument to a method that requires an int32 input, for example.

I think the onus should be on the programmer here -- if they are working with numbers that need to go larger than what can be held in 32 bits, then they should write their function to use 64-bit numbers explicitly. I don't think the compiler should try to guess their intentions and "correct" by changing 32-bit ints to 64-bit ones.

I would recommend that overflows from int32 or uint32 be treated as such, and not turned subtly into in64 or uint64. For one thing, some algorithms make use of overflows as a feature. Also, then you don't have issues with a variable having been changed subtly to some other type (say int64), and then being used later as an argument to a method that requires an int32 input, for example. I think the onus should be on the programmer here -- if they are working with numbers that need to go larger than what can be held in 32 bits, then they should write their function to use 64-bit numbers explicitly. I don't think the compiler should try to guess their intentions and "correct" by changing 32-bit ints to 64-bit ones.

lriesebos commented

2021-03-10 01:45:14 +08:00

I agree with @dhslichter .

pca006132 commented

2021-06-07 10:16:54 +08:00

This is now mentioned in the current README.

pca006132 closed this issue

2021-06-07 10:16:54 +08:00

Sign in to join this conversation.

No Label

No Milestone

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3-spec#2