Hacker News Reader

Comment by Sharlin | Hacker News Reader

As an aside:

> Rust's "orphan rule" allows writing a trait impl only if either your crate defines the trait or defines one of the types the impl is for. That means if your code uses a type defined outside of your crate without a Serde impl, you resort to newtype wrappers or other obnoxious workarounds for serializing it.

I hadn't realized this. The justification is reasonable - preventing ambiguity when resolving traits - but it precludes one of the major use cases for traits/type classes: adapting a type from one library to an interface in another library without wrapper types.

View on HN

This is true, however you can get around a lot of the annoyance of it with conversion traits like From<T> and Into<T>.

It still takes a bit of boilerplate to write unfortunately.

The good news is this likely won't be the case forever, it looks like specialization (I think it's called) and some other type system features will allow you to write some code to resolve this. Intersection impl's I think it's called. Correct me if I'm wrong anyone.

Luckily, because of rust's "newtype" types and the Deref trait, wrapping isn't too much of a pain.

Yeah, in Haskell it's allowed but outputs a warning. So a lot of my modules use -fno-warn-orphans :D

The reason is that class instances are really not first-class in Haskell. You can never import a module and choose not to import its instances, not even with

  import Module (just_one_symbol_i_need)

or to not import a couple of them. I think named instances a la PureScript let you do

  import Module (instance toJsonText, ...)

which would be great to have in Haskell, but probably breaks something deep inside instance resolution.

PureScript as a "Haskell without the mistakes" really is a great idea.

Reply on news.ycombinator.com