Comment by JoshTriplett

9 months ago

Someone who has experienced real problems as a result of a specific mechanism is not required to solve every single problem with alternatives to that mechanism before saying "this mechanism has caused me real problems and it'd be nice if there were a better alternative that didn't cause those problems".

> The moment you allow this, you have to find a way to pick between several implementation - and they don't always have sane names.

There are other possible solutions that don't involve that.

For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.

A slightly more sophisticated rule would be "Identical implementations are allowed and treated as a single implementation". This would be really convenient in combination with some kind of "standalone deriving" mechanism, which would generate identical implementations wherever it was used.

7 comments

JoshTriplett

Reply
Ygg2  9 months ago

Disclaimer: I'm aware you guys are working on relaxing orphan rules, and I wish you the best of luck. But as an outsider, orphan rule doesn't seem to be going anywhere soon.

And if the original poster had said that I would be ok. Instead what they said is:

> It's a great example of something I'd call "muh safety", desire for perfection and complete avoidance of all problems at all costs, even if it means significantly worse developer ergonomics.

This implies the writer didn't assume what happens if you "turn-off" orphan rules. I.e. you don't trade perfection for developer ergonomics, you trade one set of developer (ability to write any trait for any type) ergonomics for another (having to battle two incompatible trait implementations from crates you don't own).

Either you have to manually specify how nearly every implementation is pulled (horrible developer ergonomics) or, even worse, you go into monkey patching territory.

> For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.

Ok. But you still need a resolution mechanism to fix the error. Which implies manually solving ambiguity. And how do you solve it for blanket implementations?

  • JoshTriplett  9 months ago

    > But you still need a resolution mechanism to fix the error

    At least initially, the resolution mechanism could be "don't include more than one implementation".

    • Ygg2  9 months ago

      Assuming you have no control over trait implementation, how would that work?

      To reuse the canonic example:

          // crate "types"

    pub struct Thing;

    // crate "traits"

    pub trait Action {}

    // crate "alpha_v0" 

    impl traits::Action for types::Thing {}


    // crate "beta_v1" 

    impl traits::Action for types::Thing {} // Doesn't exist for beta_v0

      Say by transitive dependencies, alpha_v0 and beta_v0 are imported, and due to vulnerability, you upgrade beta_v0 -> beta_v1 (let's assume that trait is essential for the vulnerability resolution).

      Now what? You either have to skip future updates, or keep the vulnerable beta_v0 crate.

      2 replies →

  • Capricorn2481  9 months ago

    > This implies the writer didn't assume what happens if you "turn-off" orphan rules

    It implies that the writer would prefer using a different language, not that Rust would be better if it was all the same but with the parts he doesn't like taken out

    • Ygg2  9 months ago

      > It implies that the writer would prefer using a different language

      That's not what they wrote.

      > There are mostly valid reasons for wanting the orphan rule for things such as libraries uploaded to crates.io, and I am willing to concede that crates published there should obey this.

      > But I have a very hard time caring about this rule for applications and libraries developed in end products. I'm explicitly not saying binary crates, because most bigger projects will be composed of more than one crate, and many will be more than one workspace.

      It talks explicitly about Rust. In hindsight, the author might have been better suited by another language, but expecting Rust to suddenly become another language is weird.