Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Yes, so, the situation is:

    #![feature(type_name_of_val)]
    
    fn main() {
        let v = vec![1, 2, 3];
        
        let x = 1;
        let y = 1;
        
        v[x];
        
        dbg!(std::any::type_name_of_val(&x));
        dbg!(std::any::type_name_of_val(&y));
    }

gives

  [src/main.rs:11] std::any::type_name_of_val(&x) = "usize"
  [src/main.rs:12] std::any::type_name_of_val(&y) = "i32"

https://play.rust-lang.org/?version=nightly&mode=debug&editi...

View on HN

This type inference at a distance thing is unsettling to me. Adding

    v[y];

much later in the function (after your debugs) quietly changes everything above it...

Type inference works only when the types are unambiguous - arrays don't support indexing by anything else. With strict typing and very few implicit conversions in the language it works very well without surprises. You can still declare types ahead of time if you want to.

> Type inference works only when the types are unambiguous

It looks to me like when the types are ambiguous (because nothing placed a restriction on them), integer literals become 32 bit and floating literals become 64 bit. Then quietly, later when you add a restriction, the code above (which you've already worked through one line at a time with debug statements and all) changes from underneath you.

> You can still declare types ahead of time if you want to.

When the implicit stuff is surprising, I'd rather it wasn't ever implicit.

pornel is right, but to be extra clear: if that happened and the types were mis-matched, it’s not very quiet: you’d get a compiler error. We don’t implicitly coerce numerics.

I think the i32 default for integer literals stands in contrast to the otherwise solid choices for numerics on builtin types in Rust.

What would you prefer?

Personally I would prefer i64, but the following are defensible:

- Treat it as a special arbitrary precision type, similar to Go

- Choose isize because it's the native size for the platform

- Make it a compile error when the type can't be inferred

The rationale for i32 in RFC 0212 is basically, "well C compilers usually do this", and some hand waving about cache (why not i16 or i8 then?!?). Then they chose f64 instead of f32 for floating literals, which undermines the cache argument. So really, Rust did it because C compilers do it, and C compilers do it to simplify porting old software, which doesn't apply to Rust.

We did option 3, and it made examples and docs very difficult.

Option 1 is not acceptable given Rust's attitude towards allocation.

We could do option 2, it's true.

> The rationale for i32 in RFC 0212 is basically, "well C compilers usually do this"

I don't agree with this; but it doesn't really matter at the end of the day, it's been years and this can't really change.

Regardless, I appreciate the elaboration :) It helps me understand the way others think about Rust.

Yeah, I realize none of this can change. However, if there is ever a breaking version 2.0 on the roadmap, I'll tell you the features which keep me from actually using Rust. The i32 is pretty insignificant. :-)

There is no plans at this time, but I'm always interested in hearing what folks have to say...

Tangentially, Rust goes well out of its way to avoid "type inference at a distance". For example, unlike Haskell or most MLs, type inference will not work across a function boundary.

Here's one that caught me off guard:

    #[derive(Debug)]
    struct Foo<T> { pub bar: T }

    fn hmm<T>(x: T) -> Foo<T> {
        Foo { bar: x }
    }

    fn main() {
        let f:Foo<f32> = hmm(1.23);
        print!("got: {:?}\n", f);
    }

So maybe that's not crossing function boundaries, but the type for the generic "hmm" function as the rvalue is being inferred from the explicitly declared type of the lvalue. I know it's pointless to try and change anyone's mind about this, but I personally find it unsettling :-)

Reply on news.ycombinator.com