Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use different orphan rules for different traits #15

Open
Ixrec opened this issue Jul 7, 2018 · 1 comment
Open

Use different orphan rules for different traits #15

Ixrec opened this issue Jul 7, 2018 · 1 comment

Comments

@Ixrec
Copy link
Owner

Ixrec commented Jul 7, 2018

The main use case here is binary operator traits. "Little Orphan Impls" discusses this use case a lot but ends up arguing that ordering should matter, and it does matter in today's rules, which is a surprise people usually encounter with the binary operator traits.

https://internals.rust-lang.org/t/coherence-rules-for-generic-binary-operator-traits/4778/10 suggests that we could simply make these traits use different orphan rules where ordering does not matter. https://internals.rust-lang.org/t/orphan-rules/1322/11?u=ixrec suggests manually specifying the ordering for orphan rules separately from the actual ordering of type parameters in the public API.

Since changing which orphan rules apply to a trait would obviously be backwards incompatible (and no, even editions can't change that), we probably can't actually do this for std's operator traits. Are there any use cases with third party traits where this would help?

@Ixrec
Copy link
Owner Author

Ixrec commented Jul 8, 2018

Looks like Scala is considering letting type classes declare whether or not they should be coherent, which is sort of the logical extreme of this idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant