Idea: allow inherent impls which follow coherence rules

language design
1

Inherent impls are more restricted than trait impls.

You can do this:

impl LocalTrait for ForeignStruct<LocalStruct> {}

You can't do this:

impl ForeignStruct<LocalStruct> {}

I propose relaxing this restriction for inherent impls, and permitting any impl that would pass the orphan rules. Are there downsides to this?

1 Like
2

Say you had:

impl ForeignStruct<YourLocalTy> {
    fn something …
}

What if the upstream crate then did:

impl<T> ForeignStruct<T> {
    fn something …
}

That would yield an overlap for T = YourLocalTy. It's basically the same issue as with a non-inherent impl of a RemoteTrait: either the trait or the type would have to be marked #[fundamental] to express that such impls would not occur within semver-compatible versions.

In the meantime, I suggest that you use something like:

which greatly reduces the boilerplate of writing extension traits, hence yielding 95% of the ergonomics of inherent impls to begin with:

#[extension(trait MyLogic)]
impl<T, U> ForeignStruct<T, U, YourLocalTy> {
    …
}
4 Likes
3

You are completely right. Thanks for educating me

1 Like
4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.