Arbitrary : negative impl of Arbitrary on never type (!) #332
Conversation
| @@ -56,6 +56,8 @@ atomic64bit = [] | |||
| # passed (see https://github.com/proptest-rs/proptest/issues/124). | |||
| break-dead-code = [] | |||
|
|
|||
| never-arbitrary = [] | |||
There was a problem hiding this comment.
Wasn't sure whether or not to just roll this in to the unstable feature flag. Opinions?
There was a problem hiding this comment.
Seems like a reasonable idea for stability as this is a fairly new area in the rust lang - (see my message below about coherence rules)
| @@ -56,6 +56,8 @@ atomic64bit = [] | |||
| # passed (see https://github.com/proptest-rs/proptest/issues/124). | |||
| break-dead-code = [] | |||
|
|
|||
| never-arbitrary = [] | |||
There was a problem hiding this comment.
Seems like a reasonable idea for stability as this is a fairly new area in the rust lang - (see my message below about coherence rules)
| } | ||
| } | ||
|
|
||
| impl Arbitrary for Wrapper<!> { |
There was a problem hiding this comment.
unfortunately, due to coherence rules, this won't be possible to implement if Wrapper is defined in another crate as the rust trait coherence rules considers it to be a conflicting implementation.
Without this PR the error looks like this
19 | impl<T: Arbitrary> Arbitrary for Wrapper<T> {
| ------------------------------------------- first implementation here
...
28 | impl Arbitrary for Wrapper<!> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Wrapper<!>`
|
= note: upstream crates may add a new impl of
trait `_IMPL_ARBITRARY_FOR_Wrapper::_proptest::arbitrary::Arbitrary` for type `!` in future versions
With this PR it still doesn't work, and the error looks like this
error[E0119]: conflicting implementations of trait `_IMPL_ARBITRARY_FOR_Wrapper::_proptest::arbitrary::Arbitrary` for type `Wrapper<!>`
--> src/main.rs:13:10
|
13 | #[derive(proptest_derive::Arbitrary, Clone, Debug)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Wrapper<!>`
...
32 | impl Arbitrary for Wrapper<!> {
| ----------------------------- first implementation here
|
= note: this error originates in the derive macro
`proptest_derive::Arbitrary`
(in Nightly builds, run with -Z macro-backtrace for more info)
There is an initiative inside of rustc to integrate negative impls into trait coherence rules, but until then this will be insufficient.
rust-lang/negative-impls-initiative#1
I originally thought this would be a strict improvement, but actually judging from the error messages (IMO they end up regressing) - I think this is probably premature and should wait until the negative impls initiative furthers.
Perhaps hiding it behind another feature flag like you did is a good way to mitigate this concern!
fixes #331