regression: conflicting implementations between `#[fundamental]` generic type and `FnPtr` about rust HOT 5 CLOSED

It's likely due to 66d7cfd.

This isn't probably worth tracking as a regression since fundamental should probably be marked an internal feature, since the semantics of #[fundamental] (especially its interaction w blankets and rustc_deny_explicit_impl impls) is kinda a detail we shouldn't expose...

from rust.

My reading of that issue does not lead me to believe this chance was intentional, hence a 'regression', unless the term 'regression' isn't applicable to nightly-to-nightly.

fwiw nightly-to-nightly is considered a regression usually, you just were indeed using what I am... pretty sure was always intended to be a perma-unstable API?

from rust.

Maybe someone knows why the same issue doesn't affect Box, which is also #[fundamental], generic, and implements PartialEq. That could be a workaround.

Oh, right; because of negative coherence. We have an implicit impl !FnPtr for most types built-in to the compiler.

@finnbear: You can add #![feature(with_negative_coherence)] to your crate to make this work.

from rust.

You can add #![feature(with_negative_coherence)] to your crate to make this work.

Thanks very much, I think this solves my problem (cannot be 100% yet since still dealing with new ICE's). Closing as there is less motivation to restore the old behavior now that a workaround exists.

from rust.

Regardless of stability, I'm under the impression that the old behavior is desirable and recoverable (such as by ignoring conflict implementations of FnPtr if impl FnPtr is truly disallowed). However, if there is intent or motivation to keep the new behavior, you're right that it wouldn't violate any stability guarantee.

Maybe someone knows why the same issue doesn't affect Box, which is also #[fundamental], generic, and implements PartialEq. That could be a workaround.

from rust.