4 ms·

> seeing "WGPUSwapChainId" tells me exactly what sort of object is returned (a reference to some object held elsewhere) Check out RLS (the rust language server

> seeing "WGPUSwapChainId" tells me exactly what sort of object is returned (a reference to some object held elsewhere) Check out RLS (the rust language server) to get intellisense like this working in your favorite editor.

jonathanyc 8y ago
I think that in reviewing code this is definitely something where languages with type inference lose clarity; Rust is even worse because of the Deref/Into idioms. I think the solution is for diff viewers incl. those on the web to support something like intellisense, but obviously we are a very long way away from that.
- devit 8y ago
  You could have the compiler produce a fully explicit version (I'm not sure if Rust can do that out of the box at the moment)
  - steveklabnik 8y ago
    ~~It can't.~~ See below, it can! I tend to find, personally, that this kind of thing doesn't interfere strongly with reviewing. I think this is because I have an extensive background in dynamically typed languages and ones with strong inference like Rust, so I'm more used to it, whereas people who don't come from said backgrounds prefer more explicitness. YMMV of course!
    - jonathanyc 8y ago
      I don’t think it’s just “strong” inference that’s the problem; I find I have an easier time reading ML because the inference somehow feels more obvious. After thinking about it some more, I think it really is deref coercion that is the gotcha, especially with function chaining.
      - steveklabnik 8y ago
        By "strong" I really mean "type inference" over "type deduction", to be clear. But yeah, I could see that.
    - Tohquai7 8y ago
      It can. -Z unstable-options -Zunpretty=hir,typed // source pub fn square(num: i32) -> i32 { num * num } // expanded use ::std::prelude::v1::*; extern crate std; pub fn square(num: i32) -> i32 ({ ((num as i32) * (num as i32) as i32) } as i32) You can try on https://rust.godbolt.org/ https://rust.godbolt.org/
      - steveklabnik 8y ago
        Oh dang! That's very cool, thank you!

jonathanyc 8y ago

I think that in reviewing code this is definitely something where languages with type inference lose clarity; Rust is even worse because of the Deref/Into idioms. I think the solution is for diff viewers incl. those on the web to support something like intellisense, but obviously we are a very long way away from that.

devit 8y ago
You could have the compiler produce a fully explicit version (I'm not sure if Rust can do that out of the box at the moment)
- steveklabnik 8y ago
  ~~It can't.~~ See below, it can! I tend to find, personally, that this kind of thing doesn't interfere strongly with reviewing. I think this is because I have an extensive background in dynamically typed languages and ones with strong inference like Rust, so I'm more used to it, whereas people who don't come from said backgrounds prefer more explicitness. YMMV of course!
  - jonathanyc 8y ago
    I don’t think it’s just “strong” inference that’s the problem; I find I have an easier time reading ML because the inference somehow feels more obvious. After thinking about it some more, I think it really is deref coercion that is the gotcha, especially with function chaining.
    - steveklabnik 8y ago
      By "strong" I really mean "type inference" over "type deduction", to be clear. But yeah, I could see that.
  - Tohquai7 8y ago
    It can. -Z unstable-options -Zunpretty=hir,typed // source pub fn square(num: i32) -> i32 { num * num } // expanded use ::std::prelude::v1::*; extern crate std; pub fn square(num: i32) -> i32 ({ ((num as i32) * (num as i32) as i32) } as i32) You can try on https://rust.godbolt.org/ https://rust.godbolt.org/
    - steveklabnik 8y ago
      Oh dang! That's very cool, thank you!