rust-lang
RFC: Allow generic impls using local trait bounds
This proposal was initially shared in a Reddit post I authored to introduce the idea and gather community feedback:
“Proposal to reconcile generics and Rust’s orphan rule”
While the post is still recent and awaiting responses, it serves as an early exposition of the problem and the motivation behind this RFC.
The example is confusing. What exactly is Calculable? The name makes it sound like a trait but it appears to be a type. It seems like the LocalToThisCrate version would result in not only Vec2 + Point and Point + Vec2 producing Calculable, but also Vec2 + Vec2… is that really what you want?
The error message example also doesn’t make sense. Why would the compiler complain that “T may be a type defined outside of the current crate” when T is an unknown type that’s specifically required to be LocalToThisCrate?
Was this written with the help of AI? The writing style kind of feels like it.
Anyway, this feature doesn’t seem logically unsound, and it might be helpful for some use cases. But I don’t think it would address the most common pain points caused by the orphan rule. Those usually involve wanting to actually impl foreign traits for foreign types, as opposed to just wanting shorthand for writing a bunch of impls for local types.
In the case of addition between point and vector this represents a transition and an addition between 2 points as well as a division by 2 corresponds to the midpoints. The computable type here would be a 2-dimensional tuple. The error message is more there to illustrate the fact that we cannot use external types because they do not implement this trait (by definition). Yes, I originally speak French and this is my first time writing an RFC. I thought using AI would allow for a better translation, but I'm not sure it was the best choice. I'm glad to have received such a quick response, if you have any other questions please don't hesitate to ask, I'll be happy to answer them.
Le mar. 27 mai 2025, 22:09, comex @.***> a écrit :
comex left a comment (rust-lang/rfcs#3821) https://github.com/rust-lang/rfcs/pull/3821#issuecomment-2913887158
The example is confusing. What exactly is Calculable? It seems like the LocalToThisCrate version would result in not only Vec2 + Point and Point
- Vec2 producing Calculable, but also Vec2 + Vec2… is that really what you want?
The error message example also doesn’t make sense. Why would the compiler complain that “T may be a type defined outside of the current crate” when T is an unknown type that’s specifically required to be LocalToThisCrate?
Was this written with the help of AI? The writing style kind of feels like it.
Anyway, this feature doesn’t seem logically unsound, and it might be helpful for some use cases. But I don’t think it would address the most common pain points caused by the orphan rule. Those usually involve wanting to actually impl foreign traits for foreign types, as opposed to just wanting shorthand for writing a bunch of impls for local types.
— Reply to this email directly, view it on GitHub https://github.com/rust-lang/rfcs/pull/3821#issuecomment-2913887158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQPFSZYD7C6NMO7VZF3TTD3ATA53AVCNFSM6AAAAAB6A5MJK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJTHA4DOMJVHA . You are receiving this because you authored the thread.Message ID: @.***>
I’ll second @comex; the example provided makes the feature look like one with situational utility.
One interesting thing that could be done with LocalToThisCrate is to use it as a supertrait to make the subtrait sealed.
I recently made a small post on the Internals forum proposing something similar to this, though I had a different use-case in mind. I am glad to see a related idea as a proper RFC.
My internals post doesn’t propose any sort of LocalToThisTrait trait; instead, you define your own trait, and when checking the orphan rules, the compiler verifies when necessary that there are no impls of the trait for upstream types. A major advantage of this is that downstream crates might be able to implement the trait as well.
I thought using AI would allow for a better translation, but I'm not sure it was the best choice.
A big sign of this is that there is a lot of “fluff” and vague/generic language in the RFC currently, especially in later sections (“Prior Art” and following). An RFC is not a box-checking exercise or something with a minimum/maximum word count. The goal is to provide all the info that the lang team will need when they discuss and decide on the proposal. They are always very busy—too many proposals, too little time—so you want to make it easy for them. If a sentence or paragraph doesn’t contribute to that, cut it out. And if it is an important detail, or something they might have questions about, then make sure it’s explained with concrete examples that demonstrate the full implications.