Playing with Rust's tuples - tuples

Question

Here's the link where was playing with Rust:
http://rustbyexample.com/match/guard.html
I found Rust showing warnings for the case when i negate an unsigned variable, so executing code below ends with
warning: negation of unsigned int variable may be unintentional
Code:
fn main() {
let some = 2953495866u;
let pair = (some, -some);
// TODO ^ Try different values for `pair`
println!("Tell me about {}", pair);
// Match can be used to destructure a tuple
match pair {
// Destructure the tuple
(x, y) if x == y => println!("These are twins"),
// The ^ `if condition` part is a guard
(x, y) if x + y == 0 => println!("Antimatter, kaboom!"),
// `_` means don't bind the value to a variable
(x, _) if x % 2 == 1 => println!("The first one is odd"),
_ => println!("No correlation..."),
}
}
But when you change the code into somewhat like
let pair = (2953495866u, -2953495866);
it runs silently ending up with tuple of (2953495866, 18446744070756055750) what is 2 unsigned integers. As for me, i'd rather expect warning here about casting negative number into uint.
What do you think about this situation?

Answer 1

An explanation, just in case. In this code:
fn main() {
//let some = 2953495866u;
let pair = (2953495866u, -2953495866);
// TODO ^ Try different values for `pair`
println!("Tell me about {}", pair);
// Match can be used to destructure a tuple
match pair {
// Destructure the tuple
(x, y) if x == y => println!("These are twins"),
// The ^ `if condition` part is a guard
(x, y) if x + y == 0 => println!("Antimatter, kaboom!"),
// `_` means don't bind the value to a variable
(x, _) if x % 2 == 1 => println!("The first one is odd"),
_ => println!("No correlation..."),
}
}
-2953495866 literal is untyped; it means that the type checker can deduce its concrete type from its usage. It turns out that it is stored into a tuple and then this tuple is destructured and its two components are compared. Because the first component type is uint (because the corresponding literal has u suffix), the type checker decides that the second component type is also uint, hence that literal should be uint as well.
That the lint about negation of unsigned value is not fired does seem like a bug in the compiler. I've submitted it here.