Unsigned integer type inference

[artemkin]

Ok, let me clarify the question a bit.

I’m aware of overflow checks in debug and their absent in release builds, and it is obviously good solution.

I’m wondering why this code is not rejected by compiler? It is error-prone code, isn’t it? I would rather add some explicit type annotation to make it compilable.

Actually, your code does not mix signed and unsigned types, a, b, c, d are all u32. Subtraction of unsigned integers is defined in Rust.

Yes, I understand, but even if it is due to type inference rather than integral promotion in C++, it has absolutely the same result: implicit switch from signed to unsigned arithmetic.

Unsafe means something very specific in Rust. Over/underflow cannot cause memory unsafety, even though it’s obviously not desireable.

This code leads to unexpected switch from signed to unsigned arithmetic, it is not about over/underflow.

[matklad]

it has absolutely the same result: implicit switch from signed to unsigned arithmetic.

As far as I understand, there is no signed arithmetic in your example. All initial values and all intermediate values are u32. May be there is a terminology issue here? What is your definition of unsigned and signed arithmetic?

I’m wondering why this code is not rejected by compiler?

It is impossible to predict at a compile time if acertain operation will overflow, hence the run-time checks.

Also, it is hard to reason about a piece of code like let a = 2

You can use a literal suffix to make this obvious:

let a = 2u32;
let b = 2u64;
let c = 2i64;
let d = 2isize;
let e = 2usize;

[matklad]

@artemkin do you want this code to be rejected?

let a = 6u32;
let b = 2u32;
let c = a - b;

?

[artemkin]

No. It is absolutely valid and explicit unsigned code.

The same as

let a = 6;
let b = 2;
let c = a - b;

is absolutely valid signed code (don’t you expect unsigned arithmetic by default, do you?).

The problem is that adding

let d = c / some_unsigned_val

implicitly changes signed code to unsigned.

[matklad]

Hm, I still don’t get this…

2u32 - 6u32 == 4294967292u32 <- this is valid, because we overflow aka wrap aka make calculations in Z/2^32 aka calculate modulo 2^32

4294967292 / 2 == 2147483646 <- this is valid in almost every imaginable sense (although I can image a case when it is invalid )

[cuviper]

2u32 - 6u32 == 4294967292u32 <- this is valid, because we overflow aka wrap aka make calculations in Z/2^32 aka calculate modulo 2^32

Wrapping is subject to debug asserts. Release mode doesn’t check it, but debug builds will panic.

[artemkin]

Ok, read this code. It is pretty straight forward isn’t?

fn print_foo(foo: Foo) {
   let a = 2;
   let b = 6;
   let c = a - b;
   let d = c / foo.count;
   println!("{}\n", d);
}

fn main() {
   let foo = Foo { count : 2 };
   print_foo(foo);
}

Sure, Foo is defined in another module/file/library, as it is usually is in non-trivial code. One morning someone changed Foo definition from

struct Foo {
   count: i32
}

to

struct Foo {
   count: u32
}

make sense?

[matklad]

Hm, I’ve found one more potential source of confusion here. Integer literals without suffixes are polymorphic. Their type is inferred from use, if it is unambiguous, and defaults to i32 (am I correct here?) if it is not constrained.

That is, in the following code

let c = 92;

The c can have any integral type, and you need to see usages of c to determine it’s precise type. In your first example,

let a = -2;
let b:u32 = 2;
let c = a / b;

all three variables are typed as u32 because of the explicit annotation for b.

So this

let a = 6; let b = 2; let c = a - b;

is absolutely valid signed code (don’t you expect unsigned arithmetic by default, do you?).

Is not always true. There is not enough information to say if these are signed or unsigned numbers. If the next line is, say, let d = c / 2u32 then these are signed 32 numbers. But if the next line is let d = c * 92i64 these are signed 64 bit numbers.

This looks complicated, but in practice is rarely a problem. Oftentimes you have an explicitly typed variable in the expression, and you can always use suffixes. Please not also that the issue is not with type of an arithmetic expression, but with the type of a literal.

[matklad]

Yes, this is a potentially problematic example, but it is only because the d is not actually used anywhere.

If it was

fn make_d(foo: Foo) -> i32 {
   let a = 2;
   let b = 6;
   let c = a - b;
   let d = c / foo.count;
   d
}

then you’d get a compilation error.

[artemkin]

This is error-prone even if d is returned from the function:

fn change_foo(foo: Foo) -> Foo {
   let a = 2;
   let b = 6;
   let c = a - b;
   let d = c / foo.count;
   Foo { count : d }
}

[cuviper]

One morning someone changed Foo definition

Your types were unspecified, so they get inferred from Foo::count. If someone changes that API, the inference will follow the change too.

What do you wish would happen?

[matklad]

Yes, in such case the only guarantee is a type annotation on any variable or a suffix on any literal. I think it’s a dilemma of static polymorphism in general:

• if you change a type, you don’t need to change all it’s usages and it’s good.
• if you change a type, the semantics of each usage is silently changed and you are not warned by a compiler error and it’s bad.

Here is an example of a similar issue without integers:

struct A;
struct B;

impl Default for A {
    fn default() -> A { A }
}

impl Default for B {
    fn default() -> B { B }
}


trait T {
    fn do_something(&self);
}

impl T for A {
    fn do_something(&self) {
        // Make something good.
    }
}

impl T for B {
    fn do_something(&self) {
        panic!("Destroy the world.")
    }
}


struct Foo {
   field: A
}


fn act(foo: Foo) {
    foo.field.do_something();
}

fn main() {
   let foo = Foo { field: Default::default() };
   act(foo);
}

[cuviper]

FWIW, there was a period of time when there was no implicit fallback type at all. If an unsuffixed literal couldn’t be inferred, you’d get an error. So your example of “let a = 2; let b = 6; let c = a - b;” would have failed if there was nothing else to infer the exact type.

RFC 212 restored the fallback as i32, which might be interesting reading for you (including PR comments).

[Gankro]

To be clear: default inference basically only kicks in for examples or unit tests. All other code I’ve ever seen pretty quickly forces the types to be concrete (either by interacting with a struct or a function). For instance, if you index into an array, it’s gotta be a usize.

The fact that you can get silly things in toy code is not particularly concerning to me.

[yigal100]

One minor caveat / question: I haven’t checked this but I’d personally expect some kind of lint/warning when a negative literal is inferred to be unsigned. I know that C programmers think that:

unsigned a = -1; 

is perfectly fine and idiomatic but even in C this is a type unsafe way of writing the equivalent type safe:

unsigned a = ~0;

[jethrogb]

I haven’t checked this but I’d personally expect some kind of lint/warning when a negative literal is inferred to be unsigned.

This will generate the first error in the first post.

[yigal100]

Oh, right

[jan_hudec]

Aside:

I know that C programmers think that:

unsigned a = -1;

is perfectly fine and idiomatic but even in C this is a type unsafe way of writing the equivalent type safe:

unsigned a = ~0;

You’ve got it mixed up (unless C and C++ differ in this point, because I checked C++ spec, not C one; I wouldn’t expect them to differ though)!

C++ requires that signed to unsigned conversion is done modulo respective generator like the rest of the unsigned math, i.e. (unsigned)-1 is equivalent to 0u - 1u.

On the other hand, bitwise negation on signed value is implementation defined. If signed values are represented in any other way than two’s complement, ~0 != -1. But the signed → unsigned conversion is defined in terms of numeric values, not bit patterns. Therefore (unsigned)~0 will not result in maximal value for unsigned on platforms with different representation than two’s complement.

[yigal100]

Thanks for the clarification.

I guess it makes sense, given that the C/C++ specs were written (long ago) to support other numeric representations than 2s complement. I haven’t taken that into account.

Of course, nowadays this is all completely redundant: exotic machines with other systems are extinct by now so all hardware is 2s complement and Rust (and other upcoming languages) are all explicitly 2s complement.

Rust already warns about let a: u32 = -1; so everything is consistent.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.