Rust shenanigans: return type polymorphism (opens in new tab)

I was under the impression that this is something you get for free with Hindley-Millner: There is nothing in there that says: This works only for parameters. As long as there are enough hints left so the compiler can find exactly 1 correct type, the inference will work.

To rephrase this: Some languages have syntax for calling functions like this:

  returned=function(arg1,arg2)

and some have it like this:

   function(arg1 in,arg2 in,returned out)

You can mechanically transform between these 2 styles. The second style works with argument-only type inference, so the compiler has no reason to have problems with the first style.

Update: I played around with it - see https://godbolt.org/z/nfjz8hKa8

I added a trait User with D6->i32 and D8->u8 implementations, and then this:

    let temp=Die::roll();
    let _:u8=User::user(temp);

The compiler can first decide which impl of User to use from the u8, namely the D8. This means it has to use the D8 variant of Die::roll. This compiles, even if the type of temp was never explicitly specified.

This means rustc is even more powerfull than the article implies. When using collect the type definition is not necessary, as long as the function contains enough hints to infer it.

I really love the incremental narrative style of this post. I got to go on the discovery ride with you and understood better than if you just explained the feature.

I fail to understand the importance of this article, why it's a shenigan. About every self respecting OO language honors and can infer return types (union or single), and follow properly the Liskov Substitution Principle (covariant returns, in opposite to args).

Next time another Rust fanboy will detect subtyping, and the strange behavior of different subtyping for return types. Inverse unification! Rust is special! Genius!

Liskov wrote that 1994.