Of course it can change, that's what removal of coherence does.

It seems to me to be a logical impossibility to allow orphan implementations, and allow crate updates, and not have trait implementations changing at the same time. It's a pick-two situation.

▲

withoutboats3 7 months ago | parent [-]

Your conclusion is correct. I'm very happy with the two that Rust picked and tired of people pretending that there will be a magical pick three option if we just keep talking about it.

▲

pornel 7 months ago | parent | next [-]

I also think Rust has picked the right default, but I wouldn't mind having an opt in to the other pair of trade-offs. There are traits like `ToSql` that would be mostly harmless. Serde has tricks for customizing `Serialize` on foreign types, and this could be smoother with language support. Not every trait is equivalent to Hash.

▲

Ygg2 7 months ago | parent | prev [-]

The problem is people want to write glue code that adds foreign traits to types they don't own.

For example they need to implement diesel trait on a type from crate they don't own (e.g. matrix)

Is it possible to square that circle? Perhaps not through traits, but something else?

	▲	withoutboats3 7 months ago \| parent [-]
		Better newtypes are the answer. Consider Java for example. In Java, interfaces are even more restrictive than traits: only the package which defines the class can implement them for that class, not even the package which defines the interface. But this is fine, because if you want to implement an interface for a foreign class, you create a new class which inherits from it, and it can be used like an instance of the foreign class except it also implements this interface. In Rust, to the extent this is possible with the new type pattern it’s a lot of cruft. Making this more ergonomic would ease the burden of the orphan rule without giving up on the benefits the orphan rule provides.