Conversation

Just out of curiosity, do you have examples of other compilers handling this case well? For... ahem... research.

I feel like I don't have a lot of examples of languages where a wrapper on an entity is routinely passed around as a proxy for the entity itself except for the ones in the same "we decided to make a mass-market version of OCaml around 2015" cohort as Rust.

Esteban K�ber –

@ekuber

I see. In OOP you'd see at most a case of Vec<T> vs T, while in languages with enums the Container<T> vs T problem crops up more often. That's fair.

Yeah. And like in C++ we have things like smart pointers/unique_ptr, but C++ doesn't work.

(...Similarly the more conventional ML have the Tag(entity) vs entity problem, but those languages seem to really dislike subtyping (ie concepts such as traits) so they can't get into this particular hole so easily.)

Actually, I wonder if Haskell has variants of this problem (because typeclasses are not completely dissimilar from traits), and what their current error message is.

traits *are* typeclasses, they follow p much all the same formalisms etc. I saw this tweet out of order and forgot to reply to it, sorry but yeah, one could translate my playground examples into Haskell, and I would if I knew a Haskell playground (and weren't passing out tired)

repl.it/@eddyb1/type-v

12:31 PM · Feb 22, 2021Twitter Web App

and this is if I change it to: `foo :: Foo -> ()` nothing amazing, really, I wonder if I should try Elixir or whatever that language is that was praised for its diagnostics

Elm?

Replying to

Elm doesn't have ad-hoc polymorphism, except for hard-wired `comparable` and `number` type parameters, so it probably won't be super helpful. Haskell does have a nice way of providing domain-specific error messages for type classes though. Not sure if it would help here though.

Replying to

For more info on this you can see this blog post: kodimensional.dev/type-errors - it's a super useful feature, but sadly not used all that much in the Haskell ecosystem.

Replying to

I didn't look at it yet but I wonder how it compared to #[rustc_on_unimplemented] but also the problem is with the Result<T, _>/Either T _ type, being used in a place where only T satisfies bounds - the specific typeclass doesn't matter and shouldn't care about accounting for th