Implement From<L> and From<R> for Either<L, R>

[futile]

I suggest adding the two impls:

impl From<L> for Either<L, R>

and

impl From<R> for Either<L, R>

(don't know the right syntax by heart)

This enables the following nice use-case:

fn foo(e: Either<i32, f32>) {
  // use e
}

fn main() {
  foo(32.into());
  foo(42.0.into());
}

Instead of explicitly writing out the type each time.

Is there a problem with this/am I missing something? Otherwise I would write up a PR. Thanks!

[cuviper]

I don't think the compiler will allow this. What if L and R are the same type? That may seem like a strange thing to have, but it is possible, and one might use that to assign some semantic difference over two sides of the same type.

[futile]

That's a good point. Is there no way to make this work? Some way to only implement this only in the case that L != R?

[cuviper]

There's currently no way to specify L != R, but I think rust-lang/rfcs#1834 would make it possible.

Then there's the problem that adding a blanket impl is a breaking change. Someone could already have their own impl From<Foo> for Either<Foo, Bar> today, where Foo and Bar are their local types.

[futile]

Doesn't look like that rfc will be merged soon or at all, but yeah it looks to be what's required.

However, I didn't notice that I could simply impl this myself, so I might just do that. Thanks for the tip! Maybe a macro in this crate like impl_from!(Either<i32, f32>); might be nice? Or maybe that's not really desired, due to being a macro etc.

[futile]

On the topic of the breaking change: With specialization, shouldn't this be non-breaking? Since an already existing impl should be strictly more specific than a blanket impl.

[cuviper]

Hmm, maybe specialization will allow this, but that's not stable yet: rust-lang/rust#31844

[futile]

Maybe those impls could also be hidden behind a non-default feature flag?

[bluss]

either is 1.0 and should avoid feature flags. I'll restart from the top, bear with me.

Similar use case scenarios:

1

fn foo(e: Either<i32, f32>) {
  // use e
}

fn main() {
  foo(32.into());
  foo(42.0.into());
}

2

fn foo(e: Either<i32, f32>) {
  // use e
}

fn main() {
  foo(Either::from(32));
  foo(Either::from(42.0));
}

3

fn foo<E>(input: E) where E: Into<Either<i32, f32>> {
  let e = input.into();
  // use e
}

fn main() {
  foo(32);
  foo(42.0);
}

My thoughts

(2) is a nicer interface than (1), and (3) is also a very nice API. The reason that much prefer 2 and 3 over 1, is that A, the trailing .into() are entirely anonymous about which conversion is being performed and B, they have been prone to type inference induced minor breaking changes in the course of Rust's evolution

(2) is nice because its no longer anonymous, it's half-explicit about the type conversion (with option to make it entirely explicit). And (3) is another nice alternative to (1) which is usually less type inference sensitive, in part because the API side (the person providing foo) has to take responsibility for the available conversions.

I also dislike (1) also makes it hard to transition to a (3)-style API if you want to add more custom conversions or make it more generic for other reasons.

Summary: prefer to design to end up with (2) or (3)

[futile]

Thanks for the extensive comment! It looks like all 3 of these would be enabled by having a impl From<L/R> for Either<L, R>, or is there something I'm missing? Also, do you see a way to make this work with the current compiler? Otherwise this would depend on specialization/the L != R PR anyway. Or would be added through a macro, but I don't really like that solution.

[JP-Ellis]

What's the status on this feature? Is there still an issue if L and R are the same type?

[bluss]

From my perspective, this feature will never be possible. L and R being equal is always going to be an issue.

I think we can close it, that's the least frustrating thing we can do, instead of holding it open as if it's a possibility. Thanks