Hacker News Reader

Comment by massysett | Hacker News Reader

auto is type inference. That's not "pythonic", that's something that statically typed languages have had for decades. Indeed, it's nothing like Python, where general practice is to pass around things derived from Object and depend on runtime typing failures.

There's also nothing Pythonic about lambdas. Come on, lisp is ancient and it has lambdas.

This article essentially says C++ got stuff that has been around for decades, and Python has stuff that vaguely resembles them, so C++ is learning from Python.

View on HN

`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/HzyM2E

Type inference: http://ideone.com/0Gv8fV, http://ideone.com/r9nHUF

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".

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.

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.

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

There will always be some who insist that only the most advanced form of X is "really" X.

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.

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.

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.

auto x = 7;

auto y = f();

Where is the type of x specified explicitly in the local context?

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;`.

>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.

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).

So your point is that some people do not consider every form of inferring the type of a variable to be type inference. I get that.

No, I am pointing out that the type is fully explicit here and not "inferred" from anything.

Type of x is a very explicit literal type. Type of y is also fully explitit, it is a 'return type of f()'. Not any different from a type of a sub-expression.

The type of f() is explicitly specified somewhere outside the local context. The type of x is not explicitly specified anywhere. It is inferred from the rhs expression.

The type 'return type of f()' is still a type. It does not matter that it is not normalised, most of the C++ types are used in a non normal form. Type 'struct MyKewlMegaStructure' is not any different and not any more "local".

How does that mean that the type of x is not inferred from something outside the local context?

Ok. Then in 'struct _abc x;' we also have a type inference. And in any sub-expression there is also a "type inference".

Although I think this kind of twisting the common term definitions is totally pointless. "Type inference" got a very well defined meaning, which got nothing to do with any kind of a type propagation - the latter term also existing for a reason, to designate a certain sort of type systems, fundamentally different from the inference-based ones.

Then a lot of what people write on this subject seems to be using incorrect terminology, including tons of stuff issued by computer science departments and wikipedia.

After digging a little deeper into the history of this terminology I have to concede that you and catnaroek are right. There was from the beginning in the 1950s a distinction that I didn't know about. So I was wrong.

Thanks to you both for enlightening me.

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.

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.

The lambdas one is the one that got me - the best word I can use for Python's lambda support is "grudgingly."

Reply on news.ycombinator.com