Explicit OIBIT impls hide the default impls

[wthrowe]

#![allow(dead_code)]

trait Foo {}
struct A<T>(T);
unsafe impl<T: Foo> Sync for A<T> {} // Comment this line and the code compiles

trait IsSync: Sync {}
struct X;
impl IsSync for A<X> {} // error: the trait `Foo` is not implemented for the type `X` [E0277]

fn main() {}

Nothing in this example opts out of Sync or contains a type that opts out, so everything should be Sync.

I suspect this is the same underlying issue as #23072, but unlike in that case this seems like something that should be allowed.

[wthrowe]

I've been experimenting with ways to fix this, and, oddly, there's a unit test checking that this doesn't work: https://github.com/rust-lang/rust/blob/master/src/test/compile-fail/typeck-default-trait-impl-precedence.rs

The OIBIT RFC seems pretty clear that this is supposed to be accepted, but I know that the rules specified there for negative impls are thought to be too lenient, so maybe this part is also frowned upon?

[nikomatsakis]

As explained in #23072, this was the semantics we implemented, which diverged somewhat from the RFC. It's interesting that this can come about without feature gates (though obvious in retrospect).

[nikomatsakis]

triage: P-medium

We discussed this last week in the language subteam meeting. Our conclusion was that there is (potentially) an issue here where the desired semantics are not entirely clear. It is backwards incompatible to fix it but deemed low risk, because the bad scenario is when one is trying to "add to" the default set that obey a particular trait (or remove further from the negative set, I suppose).

Some notes from our discussion:

The intent of an impl like this is somewhat unclear. Why did one write the impl in the first place? Was the goal to cover a case that the default rules would have excluded? Or was it perhaps to narrow down the default rules to a smaller set of acceptable cases (which kind of "opts out" by "opting in")? The latter is the current semantics; it does seem plausible that a naive read of the code might think that the impl was listing out the cases that are Sync, versus adding to an implicit set. A short-term fix we might use is to try and report errors if the impl is "unnecessary". Overall though our conclusion was the current semantics ought to be revisited with specialization in mind, since there is a lot of overlap (no pun intended!) between the situation here and that of specialization.

[brson]

Nominating for retriage and updates. Old type system issue.