upvote

points

by jadenPete4 hours ago |
comments
upvoteby SabrinaJewson1 hours ago|
next
[-]
You’re using “subtype” in two distinct, but related, senses here, and I think this should be clarified.

From a more category-theoretic perspective, a type A is a “subtype” of a type B when there is an embedding of A inside B. In this sense, `!` is a subtype of every type (which is its universal property). But this definition also grants you that `String` is a subtype of `BigInt`, because strings can be coded as bit sequences which can be coded in `BigInt`, which may or may not be what you expect.

From a programming languages perspective – and this is the terminology generally used in Rust – a type A is a “subtype” of a type B when `a: A` implies that `a: B`. In this sense, `!` is only a subtype of itself; although it coerces to any other type, it’s not _literally_ of that type, the coercion is just invisible in syntax. Importantly, if A is a subtype of B then `Vec<A>` is a subtype of `Vec<B>` – but `Vec<!>` is definitely not a subtype of `Vec<T>`, since they may have totally different layouts in memory (the former not allocating at all, while the latter potentially allocating).

reply
upvoteby kccqzy1 hours ago|
parent|
[-]
> A is a subtype of B then `Vec<A>` is a subtype of `Vec<B>`

That’s just not true. Java would permit it but then you get ArrayStoreException so this is unsound from a type system perspective. To make this sound, we need to classify each use of a type parameter to be covariant, contravariant, or invariant.

reply
upvoteby kccqzy3 hours ago|
prev|
[-]
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.

reply
upvoteby SabrinaJewson1 hours ago|
parent|
next
[-]
Do you have an example of a piece of code that behaves in a surprising way because of this rule?
reply
upvoteby kccqzy1 hours ago|
parent|
[-]
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.
reply
upvoteby kibwen1 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby kccqzy1 hours ago|
parent|
[-]
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.

reply
upvoteby kibwen2 minutes ago|
parent|
[-]
And then once you have `fn foo<T>() -> T`, what do you write in the body that allows it to typecheck?
reply