Hacker News Reader

Comment by tialaramex | Hacker News Reader

> A higher level language might choose to always represent functions with function pointers

This is a dig at C++ in case anybody didn't notice. In C++ if I write three predicates X, Y and Z which decide if a > b, b < a and a == b respectively, for two ints named a and b -- their types are identical, X, Y and Z have the same type, the type of any function which takes two integers and return a boolean even though of course these are different functions.

Imagine if your other types worked like this. Oh IPv4Address and OldMacFileType both consist of four bytes, so now they're interchangeable and your code which takes an IPv4Address also works with a OldMacFileType. Very sensible.

As with many things in C++ this is inherited from C where it wasn't considered a bad problem because nobody has a decent optimising compiler on the PDP-11 anyway.

View on HN

I'm not sure I understand the criticism. You have three functions of type (int, int) -> bool. Where the type system accepts one, it accepts the others. I fail to see the issue here? How is the type system supposed to distinguish them? It's up to you, the developer, to do it. If you have two ints x and y, and you mess up and pass y to a function where you wanted to write x, the compiler is never going to catch it for you either.

I have three different functions, and what you wrote is not their type, that's their signature. Actually they are really only two different functions - a < b and b > a are the same thing for this integer type - but whether or not the optimiser knows that will not always be obvious.

Yes, the C++ type system doesn't express this, that's the defect (well, it's the consequence here of a larger defect).

Once they have different types there are two different interesting things we can do, we could just coerce them into a function pointer type based on the signature which is what you've seen in C++ and seem to assume is just naturally the only possibility. Or, we can use parametric polymorphism.

What do you mean by the "type" of a function? It doesn't sound like you're using any kind of standard definition for the word.

A type. The same thing C++ does for a lambda, since you seem to understand C++ better.

Not at all, Rust and C++ are more-or-less equivalent here. In C++, like in Rust, each lambda gets a unique unnamable type, and you can use template parameters to express direct calls.

> The lambda expression is a prvalue expression of unique unnamed non-union non-aggregate class type, known as closure type, which is declared (for the purposes of ADL) in the smallest block scope, class scope, or namespace scope that contains the lambda expression.

https://en.cppreference.com/w/cpp/language/lambda

Of course, but the result is that you need to write a lambda, even when it seems redundant semantically, because otherwise the optimiser may not see what's going on, whereas in Rust the natural expression of what you meant does what you expect.

One of the compatibility snags in Rust's standard library is that although you can write "Some words".contains(char::is_whitespace) and that does what you expect, the same won't work for char::is_ascii_whitespace for historic reasons and so you need to write the lambda in that case, which is uglier. Now, in that case if you write the natural thing you get a compiler error at least, but having the unnecessary lambda be needed to get performance is worse.

I really thought this was a dig at C++. What were you thinking of?

You could use C++ lambdas instead. They're basically structs with a call operator.

See also the comparisons from the functional header https://en.cppreference.com/w/cpp/header/functional

Reply on news.ycombinator.com