Need negative trait bound

[svmk]

use std::convert::From;

struct SomeError;
enum Error<E> {
    One(SomeError),
    Two(E),
}

/// impl<E> From<SomeError> for Error<E> where E: !SomeError {
impl<E> From<E> for Error<E> {
    fn from(error: E) -> Self {
        Error::One(error)
    }
}
impl<E> From<SomeError> for Error<E> {
    fn from(error: E) -> Self {
        Error::Two(error)
    }
}

It's produces error:

rustc 1.18.0 (03fc9d622 2017-06-06)
error: main function not found

error[E0119]: conflicting implementations of trait `std::convert::From<SomeError>` for type `Error<SomeError>`:
  --> <anon>:15:1
   |
9  | / impl<E> From<E> for Error<E> {
10 | |     fn from(error: E) -> Self {
11 | |         Error::One(error)
12 | |     }
13 | | }
   | |_- first implementation hereadd
14 | 
15 | / impl<E> From<SomeError> for Error<E> {
16 | |     fn from(error: E) -> Self {
17 | |         Error::Two(error)
18 | |     }
19 | | }
   | |_^ conflicting implementation for `Error<SomeError>`

error: aborting due to previous error

May'be shall implement contruction:

impl<E> From<SomeError> for Error<E> where E: !SomeError {
  ...
}

[oli-obk]

Negative bounds have a lot of issues. Like the fact that implementing a trait becomes a breaking change. There's some related discussion in rust-lang/rfcs#1834 . There's probably more discussion in the internals forum.

[oli-obk]

Oh and you might want to have a look at specialization. I think it allows your case without the Pandora's box of issues that negative trait bounds brings with it.

[soltanmm]

AFAICT From's blanket implementation without use of the default keyword precludes specialization at the current time, unfortunately. An alternative formulation is the OIBIT trick for negative reasoning (someone mentioned this somewhere a while back; I don't remember who or where):

#![feature(optin_builtin_traits)]

trait NotEq {}
impl NotEq for .. {}
impl<X> !NotEq for (X, X) {}

struct X<A>(A);
impl<A, B> From<X<B>> for X<A>
    where
        A: From<B>,
        (A, B): NotEq,
{
    fn from(a: X<B>) -> Self { X(a.0.into()) }
}

fn main() {}

[kdy1]

Does that works for a struct with (u8, u8)? Considering how oibit (Send/Sync) works, I don't think it would..

[axos88]

+1

I'm having trouble with implementing Debug for structs that have fields which are not Debug:

enum MyOption<T> {
  None,
  Some(T)
}

impl<T> Debug for MyOption<T> where T: ?Debug {
          match self {
            None => write!(f, "Unset"),
            Some(_) => write!(f, "An unprintable value")         
        }
}
 
#[derive(Debug)]
struct Foo {
  a: u32,
  b: MyOption<SomethingWithoutDebug>
}

Another solution for my case would be if such a pattern could be implemented:

  self match {
    None => ...
    Some(x: T where T: Debug) => ...
    Some(_) => ...

[kennytm]

@axos88 This is already supported through specialization.

#![feature(specialization)]

use std::fmt::{self, Debug};

enum MyOption<T> {
  None,
  Some(T)
}

impl<T> Debug for MyOption<T> {
    default fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            MyOption::None => write!(f, "Unset"),
            MyOption::Some(_) => write!(f, "An unprintable value"),
        }
    }
}

impl<T: Debug> Debug for MyOption<T> {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            MyOption::None => write!(f, "Unset"),
            MyOption::Some(t) => t.fmt(f),
        }
    }
}

struct Unprintable;

fn main() {
    println!("{:?}", MyOption::Some(1234));
    println!("{:?}", MyOption::Some(Unprintable));
    println!("{:?}", MyOption::None::<Unprintable>);
}

[stepancheg]

@kennethbgoodin more complicated use cases are not possible with trait specialization.

For example:

#![feature(specialization)]

trait Integer {
    fn to_int(&self) -> i32;
}

trait Collection {
    fn to_vec(&self) -> Vec<i32>;
}

trait PrintAnything {
    fn print(&self) -> String;
}

impl<T> PrintAnything for T {
    default fn print(&self) -> String {
        format!("unprintable")
    }
}

impl<T: Integer> PrintAnything for T {
    fn print(&self) -> String {
        format!("int {}", self.to_int())
    }
}

impl<T: Collection> PrintAnything for T {
    fn print(&self) -> String {
        format!("collection {:?}", self.to_vec())
    }
}

error[E0119]: conflicting implementations of trait `PrintAnything`:
  --> src/main.rs:27:1
   |
21 | impl<T: Integer> PrintAnything for T {
   | ------------------------------------ first implementation here
...
27 | impl<T: Collection> PrintAnything for T {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation

error: aborting due to previous error

[kennytm]

It is possible if specialization is enhanced to recognize intersection (previously attempted in #49624) i.e.

impl<T> PrintAnything for T { ... }
impl<T: Integer> PrintAnything for T { ... }
impl<T: Collection> PrintAnything for T { ... }
impl<T: Integer + Collection> PrintAnything for T { ... }

(If you need to specialize to N traits like these you'll need 2^N impls)

[axos88]

@kennytm That doesn't seem like a solution for anything with N >= 4...

[quark-zju]

Would a subset of negative bounds be less problematic? For example, !Sized? That alone might already solve some problems.

[Ixrec]

#68004 should probably be mentioned here. It's obviously not a complete negative bounds feature, and the motivation is largely unrelated, but it's a step in this direction.