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

Named opt-in trait impls #3611

Open
crlf0710 opened this issue Apr 12, 2024 · 0 comments
Open

Named opt-in trait impls #3611

crlf0710 opened this issue Apr 12, 2024 · 0 comments

Comments

@crlf0710
Copy link
Member

We all know that from inference perspective, all impls are "global" if not excluded with coherence. So this is actually part of the "inference API" of a crate. (But not yet well documented by tools like rustdoc to this day, sadly)

I've seen many tragedies that are straightforward outcome of this.

But i feel we should have patching tools that move ourselves forward, if this is not solvable problem in the near future.

What if we could opt-out an impl from the implicit parts of inference?

Strawman proposal: Named opt-in trait impls.

#[optin_impl(u8_idx)]
impl Index<u8> for [T] {
      // impl
}

fn foo1() {
     dbg!([1,2,3][3u8]);    // Doesn't compile, because no impls is selectable
     dbg!([1,2,3][3usize]);    // Works fine as always, with `usize` as idx,
     dbg!([1,2,3][3]);    // Works fine as always, with `usize` as idx,
}

#[use_optin_impls(u8_idx, ...)]
fn foo2() {
     dbg!([1,2,3][3u8]);    // Works fine, with `u8` as idx,
     dbg!([1,2,3][3usize]);    // Works fine, with `usize` as idx,
     dbg!([1,2,3][3]);    // Doesn't compile, because two impls are both in effect     
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant