3 ms·

I'm gonna politely disagree and say, I don't think "spooky action at a distance" is very scary when it happens at build-time Much of my background is in TypeSc

I'm gonna politely disagree and say, I don't think "spooky action at a distance" is very scary when it happens at build-time Much of my background is in TypeScript, which encourages mixing and matching explicit and implicit return-types, and I don't think it's just bias when I say I broadly prefer that. Having the flexibility to decide which part of your code is driving your types in different circumstances is really helpful. And Rust already does this in lots of situations, like in variable declarations and generics; Rust closures even let you have inferred argument and return types, so it feels a little arbitrary that regular functions are one of the only places where explicit types are absolutely required Caveats: - Crate exports should definitely require explicit types, since you don't have all the callers available when you build your own code to see that you don't break the API without meaning to - Rust of course tends to be used for slower-moving and more careful projects than TypeScript, so in general I'm less bothered by having to be explicit in a Rust project than I would be in a TypeScript project - TypeScript types have no runtime footprint. They in no way affect the underlying data or how it's represented, they only describe data that has its own separate material reality. Rust being a low-level language, that isn't the case here! When the return type of a function changes, that isn't just for checking, it changes the actual runtime footprint of the function in a small way. So I could see this being a reason to keep types explicit. Though, again, Rust already does lots of type inference in other places with potentially much bigger runtime implications, like when .collect() infers the data structure the items are going to be allocated into. In all: it doesn't matter to me that much, but if it were totally up to me, I'd strongly consider allowing inferred function return-types

steveklabnik 4y ago
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.

steveklabnik 4y ago

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.