Hacker News Reader

Comment by kccqzy | Hacker News Reader

No I’m not talking about runtime conversions. I’m talking about conversions that happen at type inference time.

Rust is not a subtyping based language, except for traits and lifetimes. So statements like never being at the bottom of the type hierarchy is irrelevant here even though it is correct. If Rust had higher rank types the never type is also (forall a. a) but still it doesn’t matter. It is simply surprising for a type to be converted implicitly according to subtyping rules other than for traits and lifetimes.

View on HN

Let's avoid using the term "subtyping", which as you say is irrelevant here. The reason you need diverging functions to satisfy arbitrary type obligations (i.e. to coerce to any other type) is because otherwise anything as simple as `let x = Some(42); x.unwrap();` just completely fails to compile, because `unwrap` is internally just:

    fn unwrap<T>(t: Option<T>) -> T {
        match t {
            Some(foo) => foo,
            None => panic!()
        }
    }

...and this function couldn't otherwise typecheck because it doesn't return a `T` in the `None` branch. You need coercion here.

No you don’t need coercion. You only need polymorphism. The type of `panic!()` could be an arbitrary U, which unifies just fine with the type T here.

Generally languages with such polymorphism have a never type only because they don’t also support impredicative polymorphism.

And then once you have `fn foo<T>() -> T`, what do you write in the body that allows it to typecheck?

You still write `panic!()`. It type checks using polymorphism only, without any coercions.

But `panic!()` is just a macro invocation that needs to expand to something, and the question here is what that something ought to be in order to produce a valid program. Currently it expands to this: https://github.com/rust-lang/rust/blob/98fd715edd3a0a5aa8f20... , which is a function with a return type of `!`, which has indicated a diverging function since long before Rust even considered having a first-class never type.

Right. And the whole discussion boils down to, why can’t this function return type be polymorphic in the first place? This avoids the never type, the coercions from the never type, and all the issues caused by that described in the article.

Here’s another example:

  fn f<T>() -> T {
    loop {
      println!(“Looping”);
    }
  }

This won’t compile. How do you express to the compiler that this is correct (because the function never completes) without a never type?

Rust also doesn’t support generic function types, so a callback function returning `!` is possible, whereas one accepting a type argument and returning that type is not. You could do something clever with traits, but that requires extra work.

A lot of these things are achievable without `!`, but the compiler still needs that type internally and it pieces so nicely into the type system that I don’t see the point of bending over backwards to avoid it.

Do you have an example of a piece of code that behaves in a surprising way because of this rule?

I don’t need to write examples because the article has plenty. All the fixes that Waffle needs to fix are precisely the code that behaves in a surprising way.

None of this has anything bad to say about coercion or fallback, it's a consequence of the fact that Rust is an expression-oriented language which had expressions (like `loop {}`) which logically evaluated to the never type when in return position, and yet did not have the machinery in place to support it as a proper concept anywhere outside of return position, and so they chose the unit type as a relatively benign alternative in those contexts, which caused no problems whatsoever until the day came when they decided to actually implement the never type.

> so they chose the unit type as a relatively benign alternative in those contexts

This is what the article defines as fallback. So the issue has everything to do with fallback.

Reply on news.ycombinator.com