You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reference currently says the following for integer literals
The type of an unsuffixed integer literal is determined by type inference:
[...]
If the program context under-constrains the type, it defaults to the signed 32-bit integer i32.
This does however not work for some inherent methods of signed integer types:
traitA{fnwhat_type(&self);}implAfori16{fnwhat_type(&self){println!("i16");}}implAfori32{fnwhat_type(&self){println!("i32");}}fnmain(){let z = 1;
z.what_type();//z.is_positive(); // <- uncomment this line}
As you can see, z is under-constrained in this case. The compiler does the right thing and defaults to type i32, so calling the trait method what_type() works.
If you uncomment the inherent method call to is_positive(), z still is under-constrained in pretty much the same way as before, however, the compiler fails to default to i32 and instead prints
error: no method named `is_positive` found for type `{integer}` in the current scope
Also note that the reference says
If an integer type can be uniquely determined from the surrounding program context, the unsuffixed integer literal has that type.
But the following example show that the order of statements is important:
fnone(){// compileslet a = 0;take_some(a);
a.is_positive();}fntwo(){// does not compilelet a = 0;
a.is_positive();take_some(a);}fntake_some(var:i32){// do nothing}
I think floating-point literals have the same issue, but I haven't checked.
Uh oh!
There was an error while loading. Please reload this page.
Originally at rust-lang/rust#41060
The reference currently says the following for integer literals
This does however not work for some inherent methods of signed integer types:
As you can see,
z
is under-constrained in this case. The compiler does the right thing and defaults to typei32
, so calling the trait methodwhat_type()
works.If you uncomment the inherent method call to
is_positive()
,z
still is under-constrained in pretty much the same way as before, however, the compiler fails to default toi32
and instead printsAlso note that the reference says
But the following example show that the order of statements is important:
I think floating-point literals have the same issue, but I haven't checked.
rust-lang/rust#39255 and rust-lang/rust#40985 may be related.
The text was updated successfully, but these errors were encountered: