3 ms·

Type inference is inferring a type where none has been specified explicitly. There are certainly more or less advanced forms of it, but solving systems of type

Type inference is inferring a type where none has been specified explicitly. There are certainly more or less advanced forms of it, but solving systems of type equations is not the definition of type inference.

catnaroek 11y ago
On what type inference is, from a PL researcher: http://lambda-the-ultimate.org/node/4771#comment-75771 http://lambda-the-ultimate.org/node/4771#comment-75771
- fauigerzigerk 11y ago
  There will always be some who insist that only the most advanced form of X is "really" X.
  - catnaroek 11y ago
    ML-style type inference is hardly “advanced”. And I'm even willing to count more limited forms of inference as seen in Scala, Rust or Swift - what they have is only local, but it's actual inference. But what you're claiming is the equivalent of having a “number inference” engine that can conclude that “x = 8” from “x = 4 * 2” - that's not “inference”, it's just evaluating a single expression. Actually, what Go has is even less than that, because Go's type checker doesn't need to reduce anything.
  - fmap 11y ago
    It's more of a vocabulary issue. In PL theory "type inference" is a well-defined concept. It means that you have the ability to reconstruct the types of a program without annotations. No mainstream (imperative) programming language has type inference in this sense (for good reasons). That's why the term is usually used with a different meaning when talking about mainstream programming languages.
sklogic 11y ago
In case of a C++ auto, type is specified explicitly - it is an RHS type of an assignment. Type is not deduced here, it is symply propagated. Auto does not add anything new at all on top of the existing type checking: if for a specific LHS type a checker would normalise both left and right hand types and check for assignability, in case of auto it will assume LHS=RHS without checking anything. Therefore auto is a subset of type propagation, not type inference.
- fauigerzigerk 11y ago
  auto x = 7; auto y = f(); Where is the type of x specified explicitly in the local context?
  - catnaroek 11y ago
    In `7`. It's an `int` literal, so `x` has to be an `int`. C++ won't even do you the favor of accounting for the possibility that `x` might have some other type, say, `double`, to which an `int` can be coerced. As for why you would want C++ to infer a different type, consider `std::size_t n = 0;`.
    - fauigerzigerk 11y ago
      >In `7`. It's an `int` literal, so `x` has to be an `int` What is that other than inferring the type of x from the type of 7? Edit: You don't need to convince me that this is extremely primitive type inference. I'm not defending the quality of C++ or Go type inference at all.
      - sklogic 11y ago
        The point is that this is not a type inference, it is a restricted form of a type propagation (i.e., a subset of the pre-auto C++ type propagation, not an extension of it).
        fauigerzigerk 11y ago

catnaroek 11y ago

On what type inference is, from a PL researcher: http://lambda-the-ultimate.org/node/4771#comment-75771 http://lambda-the-ultimate.org/node/4771#comment-75771

fauigerzigerk 11y ago
There will always be some who insist that only the most advanced form of X is "really" X.
- catnaroek 11y ago
  ML-style type inference is hardly “advanced”. And I'm even willing to count more limited forms of inference as seen in Scala, Rust or Swift - what they have is only local, but it's actual inference. But what you're claiming is the equivalent of having a “number inference” engine that can conclude that “x = 8” from “x = 4 * 2” - that's not “inference”, it's just evaluating a single expression. Actually, what Go has is even less than that, because Go's type checker doesn't need to reduce anything.
- fmap 11y ago
  It's more of a vocabulary issue. In PL theory "type inference" is a well-defined concept. It means that you have the ability to reconstruct the types of a program without annotations. No mainstream (imperative) programming language has type inference in this sense (for good reasons). That's why the term is usually used with a different meaning when talking about mainstream programming languages.

sklogic 11y ago

In case of a C++ auto, type is specified explicitly - it is an RHS type of an assignment. Type is not deduced here, it is symply propagated. Auto does not add anything new at all on top of the existing type checking: if for a specific LHS type a checker would normalise both left and right hand types and check for assignability, in case of auto it will assume LHS=RHS without checking anything. Therefore auto is a subset of type propagation, not type inference.

fauigerzigerk 11y ago
auto x = 7; auto y = f(); Where is the type of x specified explicitly in the local context?
- catnaroek 11y ago
  In `7`. It's an `int` literal, so `x` has to be an `int`. C++ won't even do you the favor of accounting for the possibility that `x` might have some other type, say, `double`, to which an `int` can be coerced. As for why you would want C++ to infer a different type, consider `std::size_t n = 0;`.
  - fauigerzigerk 11y ago
    >In `7`. It's an `int` literal, so `x` has to be an `int` What is that other than inferring the type of x from the type of 7? Edit: You don't need to convince me that this is extremely primitive type inference. I'm not defending the quality of C++ or Go type inference at all.
    - sklogic 11y ago
      The point is that this is not a type inference, it is a restricted form of a type propagation (i.e., a subset of the pre-auto C++ type propagation, not an extension of it).
      - fauigerzigerk 11y ago