4 ms·

One place where I've found inference to be absolutely essential is some of the more complex asynchronous Rust code. There are probably a handful of issues at p

One place where I've found inference to be absolutely essential is some of the more complex asynchronous Rust code. There are probably a handful of issues at play here, but the end result is that often it is very hard to even know the exact type of a value. Sometimes, even if I have a feeling of what it is, the exact type incantation is hard or impossible to come up with. But if I just want to use a value where it matches an appropriate trait, I don't actually care about the exact type.

steveklabnik 7y ago
There are some cases, like closures, where the type is literally un-namable. You couldn’t write it even if you wanted to.
- ncmncm 7y ago
  Likewise in C++. And, in those cases, you really don't want to, and you know why you don't want to. But type inference in Rust and in Haskell can get pretty wacky, with the type determined by code half a page away. The built-in limits in C++ seem well-advised; anyway it is very rare to hear anyone asking for more, or complaining about code over-depending on it. It is very common, in C++, to drop in a modifier, like `auto* p = f()` for both clarity and insurance. Usually that is just the right amount of type information.
  - Quekid5 7y ago
    > But type inference in Rust and in Haskell can get pretty wacky, with the type determined by code half a page away. Hence the general guideline (in Haskell at least) that all top-level definitions should have a type ascription. You can also add ascriptions locally if you have a large function that you think would benefit (readability-wise) from it.
    - FreeFull 7y ago
      In Rust you are forced to specify the type for functions and consts/statics, there isn't any option for inference there.
      - Quekid5 7y ago
        Indeed. It's a smilar thing in Scala, and I actually find it kind of limiting because Scala (like Rust, AFAIK) doesn't have "where expressions" or "declare a function without types just because", so you're actually discouraged from making really local functions that just frobnicate-the-transmogrifier because every non-anonymous function requires a declaration. (I still very much appreciate Scala for what it is. No real experience outside of toys with Rust.)

steveklabnik 7y ago

There are some cases, like closures, where the type is literally un-namable. You couldn’t write it even if you wanted to.

ncmncm 7y ago
Likewise in C++. And, in those cases, you really don't want to, and you know why you don't want to. But type inference in Rust and in Haskell can get pretty wacky, with the type determined by code half a page away. The built-in limits in C++ seem well-advised; anyway it is very rare to hear anyone asking for more, or complaining about code over-depending on it. It is very common, in C++, to drop in a modifier, like `auto* p = f()` for both clarity and insurance. Usually that is just the right amount of type information.
- Quekid5 7y ago
  > But type inference in Rust and in Haskell can get pretty wacky, with the type determined by code half a page away. Hence the general guideline (in Haskell at least) that all top-level definitions should have a type ascription. You can also add ascriptions locally if you have a large function that you think would benefit (readability-wise) from it.
  - FreeFull 7y ago
    In Rust you are forced to specify the type for functions and consts/statics, there isn't any option for inference there.
    - Quekid5 7y ago
      Indeed. It's a smilar thing in Scala, and I actually find it kind of limiting because Scala (like Rust, AFAIK) doesn't have "where expressions" or "declare a function without types just because", so you're actually discouraged from making really local functions that just frobnicate-the-transmogrifier because every non-anonymous function requires a declaration. (I still very much appreciate Scala for what it is. No real experience outside of toys with Rust.)