I agree. Something must absolutely be done about the orphan rules, IMO they are Rust's biggest wart. They damage composition in a fundamental way, and gimp the otherwise extremely expressive trait system.
I find it hard to believe that there exists no set of import declarations which remove all ambiguity, i.e., allowing orphan traits but requiring that they get imported explicitly.
I think this is a fundamentally difficult problem. Life is sometimes not nice and you have to choose. I chose to write newtype wrappers and to accept the complexity.
> I find it hard to believe [...]
I think you should read up stuff about the orphan rule, then you will understand better.
Yes it does seem to be a very difficult problem. That being said, some hard problems deserve hard solutions!
Re:Rust's Huge Compilation Units
by tomsmeding on Tuesday June 23, 2020 @04:30AM
(#23611280)
Funny how, I believe, the terms "orphan" and "newtype" originated in Haskell and were carried over to Rust. Evidence of the functional programming heritage that Rust has, I guess.
Yes. For the unaware, the original creator of Rust wanted it to basically be OCaml with better concurrency. It used to have a more ML style syntax, green threads, etc.
This happened to me too. One important problem to overcome is the orphan rule. This means: you can only implement a trait you own or for a type you own. If both the type and the trait are not in your crate, you are out of luck.
So my first attempt failed utterly. It was very disappointing. You see, by splitting the project in different crates I put one type and one trait in different crates.
After thinking about this problem for a few weeks I accepted that I needed to write wrappers, so called newtypes. But this hurt a lot. I managed to abstract away a lot of the boilerplate by writing macros but still am not very happy about the complexity.
Growing pains.