3 ms·

It's all good! Polite disagreement is how things move forward. I think if you truly twisted my arm, I wouldn't hate the idea of non-pub things being inferred, b

It's all good! Polite disagreement is how things move forward. I think if you truly twisted my arm, I wouldn't hate the idea of non-pub things being inferred, but no further than that. I'd still choose Rust's current design, personally, but that is in fact a preference.

shadowgovt 4y ago
Agreed, because when I think of signature-inferred-by-body, I don't think of TypeScript; I think of C++ and the nature of the error messages you get when you try to use a novel type in a container template.
- estebank 4y ago
  It's also not an all or nothing rule: `type Alias = impl Trait;` will have in effect the same issues that return and argument type inference could have, and I am convinced that the issues around diagnostics caused by type errors involving it can be made almost as clear as E0308 is already today. I also believe that Rust can afford to have type inference in functions, but only for crate-local functions, I wouldn't ever want to see a `pub fn foo(x: _) -> _ {}` be allowed. Your type signatures are a contract. You can have a "gentleman's agreement" within your own project, but you want a signed and notarized contract with everyone else :) An interesting thing is that for return types all you need is evaluating the body (which is why rustc already suggests the right type when writing `-> _`, it was super-easy to implement), while parameter type inference requires global inference (which requires a full-blown change to the type checker's implementation, not as worth it for a "mere suggestion").
  - steveklabnik 4y ago
    > I am convinced that the issues around diagnostics caused by type errors involving it can be made almost as clear as E0308 is already today That's very cool! I'm glad to hear it. > An interesting thing is that Ahh, this is an interesting point for sure; I chose return values basically at random, but I can see how that's easier than parameters are. Guess that would have been an ever so slightly more strong example on my part!
dllthomas 4y ago
I think there's something to be said for allowing things to be inferred during rapid development that need to be pinned down before publishing, but once you've removed the technical barrier there's a big question of how you make sure the social side of it stays healthy.
vlovich123 4y ago
I think it might be nice to allow for inference at the pub(crate) level and below (or maybe only within a module if you wanted to be extra cautious). Now that I've had a lot of experience with TS, I'd say the probability that you accidentally change the type and the code doesn't fail is minimal, so the productivity gains of being kind to the user outweigh the value of extra verbosity. And ultimately that's all type checking is for - to make sure your types form an internally consistent system that you can reason about and avoid making mistakes on.

shadowgovt 4y ago

Agreed, because when I think of signature-inferred-by-body, I don't think of TypeScript; I think of C++ and the nature of the error messages you get when you try to use a novel type in a container template.

estebank 4y ago
It's also not an all or nothing rule: `type Alias = impl Trait;` will have in effect the same issues that return and argument type inference could have, and I am convinced that the issues around diagnostics caused by type errors involving it can be made almost as clear as E0308 is already today. I also believe that Rust can afford to have type inference in functions, but only for crate-local functions, I wouldn't ever want to see a `pub fn foo(x: _) -> _ {}` be allowed. Your type signatures are a contract. You can have a "gentleman's agreement" within your own project, but you want a signed and notarized contract with everyone else :) An interesting thing is that for return types all you need is evaluating the body (which is why rustc already suggests the right type when writing `-> _`, it was super-easy to implement), while parameter type inference requires global inference (which requires a full-blown change to the type checker's implementation, not as worth it for a "mere suggestion").
- steveklabnik 4y ago
  > I am convinced that the issues around diagnostics caused by type errors involving it can be made almost as clear as E0308 is already today That's very cool! I'm glad to hear it. > An interesting thing is that Ahh, this is an interesting point for sure; I chose return values basically at random, but I can see how that's easier than parameters are. Guess that would have been an ever so slightly more strong example on my part!

dllthomas 4y ago

I think there's something to be said for allowing things to be inferred during rapid development that need to be pinned down before publishing, but once you've removed the technical barrier there's a big question of how you make sure the social side of it stays healthy.

vlovich123 4y ago

I think it might be nice to allow for inference at the pub(crate) level and below (or maybe only within a module if you wanted to be extra cautious). Now that I've had a lot of experience with TS, I'd say the probability that you accidentally change the type and the code doesn't fail is minimal, so the productivity gains of being kind to the user outweigh the value of extra verbosity. And ultimately that's all type checking is for - to make sure your types form an internally consistent system that you can reason about and avoid making mistakes on.