4 ms·

`auto` is just bottom-up type derivation, not really type inference. Type inference lets you recover the type of a variable from how the variable is used, not j

`auto` is just bottom-up type derivation, not really type inference. Type inference lets you recover the type of a variable from how the variable is used, not just from how it is initialized. Implementation-wise, bottom-up type derivation only requires unidirectional type propagation, whereas type inference requires solving arbitrary systems of type equations. The former is a special case of the latter, where all equations are of the form “X = T”, where “X” is a type variable and “T” is an arbitrary type expression. No type inference: http://ideone.com/fmm92M http://ideone.com/fmm92M, http://ideone.com/HzyM2E http://ideone.com/HzyM2E Type inference: http://ideone.com/0Gv8fV http://ideone.com/0Gv8fV, http://ideone.com/r9nHUF http://ideone.com/r9nHUF

dllthomas 11y ago
It's clearly not type inference in its full generality (or all that close, really), but it seems a bit odd to say "X is a special case of Y; A is doing X; A is doing no Y".
- catnaroek 11y ago
  Type inference is performed by scanning the program, generating a system of type equations and solving it. If all type equations are of the form “X = T”, then there's nothing to solve.
  - fauigerzigerk 11y ago
    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
  - dllthomas 11y ago
    This doesn't really address my comment. You said two things (A, B); I pointed out that they seem incompatible; you doubled down on one of them (A). Did you intend to give up the other (B), or to refute the notion that they are incompatible? For clarity, A is "what they are doing is not type inference" and B is "what they are doing is a special case of type inference". Either of these positions seems reasonable to me, but as I noted they seem to conflict.
  - Veedrac 11y ago
    The type equations aren't all "X = T", though. Consider inference on casts, such as `{1, 2, 3}` to `std::vector`: #include<vector> float make(float) { return 0; } int make(std::vector<int>) { return 0; } int main(int, char **) { auto x = {1, 2, 3}; auto y = make(x); } You've also got return type deduction and overloading, template <typename T> auto id(T val) { return val; } int main(int, char **) { auto x = 7; auto y = id(x); } and even stupid template tricks template <typename T, typename U, typename = std::enable_if_t<std::is_same<T, U>::value>> auto add(T lhs, U rhs) { return lhs + rhs; } template <typename T, typename U, typename = std::enable_if_t<!std::is_same<T, U>::value>> float add(T lhs, U rhs) { return lhs + rhs; } int main(int, char **) { auto x = 7; auto y = add(x, x); } Whilst all the type inference is still one-directional and falls out template expansion, it's still legitimate inference.

dllthomas 11y ago

It's clearly not type inference in its full generality (or all that close, really), but it seems a bit odd to say "X is a special case of Y; A is doing X; A is doing no Y".

catnaroek 11y ago
Type inference is performed by scanning the program, generating a system of type equations and solving it. If all type equations are of the form “X = T”, then there's nothing to solve.
- fauigerzigerk 11y ago
  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
- dllthomas 11y ago
  This doesn't really address my comment. You said two things (A, B); I pointed out that they seem incompatible; you doubled down on one of them (A). Did you intend to give up the other (B), or to refute the notion that they are incompatible? For clarity, A is "what they are doing is not type inference" and B is "what they are doing is a special case of type inference". Either of these positions seems reasonable to me, but as I noted they seem to conflict.
- Veedrac 11y ago
  The type equations aren't all "X = T", though. Consider inference on casts, such as `{1, 2, 3}` to `std::vector`: #include<vector> float make(float) { return 0; } int make(std::vector<int>) { return 0; } int main(int, char **) { auto x = {1, 2, 3}; auto y = make(x); } You've also got return type deduction and overloading, template <typename T> auto id(T val) { return val; } int main(int, char **) { auto x = 7; auto y = id(x); } and even stupid template tricks template <typename T, typename U, typename = std::enable_if_t<std::is_same<T, U>::value>> auto add(T lhs, U rhs) { return lhs + rhs; } template <typename T, typename U, typename = std::enable_if_t<!std::is_same<T, U>::value>> float add(T lhs, U rhs) { return lhs + rhs; } int main(int, char **) { auto x = 7; auto y = add(x, x); } Whilst all the type inference is still one-directional and falls out template expansion, it's still legitimate inference.