Possible to implement From<Fn() -> T> and From<T> on the same type, or at least emulate it?

help
1

Let's say I have the following enum.

enum MaybeFnOrVal<T> {
    Val(T),
    Fn(Box<Fn() -> T>),
}

I’d like to be able to impl From for both of these cases.

impl<T> From<T> for MaybeFnOrVal<T> {
    fn from(v: T) -> Self {
        Self::Val(v)
    }
}

impl<F, T> From<F> for MaybeFnOrVal<T>
where
    F: Fn() -> T,
{
    fn from(f: F) -> Self {
        Self::Fn(Box::new(f))
    }
}

let x: MaybeFnOrVal<i32> = MaybeFnOrVal::from(5);
let y: MaybeFnOrVal<i32> = MaybeFnOrVal::from(|| 5);

assert!(matches!(x, MaybeFnOrVal::Val(_));
assert!(matches!(y, MaybeFnOrVal::Fn(_));

I understand these conflict with each other because T might impl Fn() → Self, but that seems like a nonsensical case.

2

Edit: I misread the OP a bit, and don't have time to try to correct it this instant, so I'll just hide the contents.

Probably irrelevant original reply

Not without specialization, or negative bounds in coherence.

fn() meets the bounds on your second implementation and creates a MaybeFnOrVal::<()>::Fn(_).

But it also meets the bounds on your first implementation and creates a MaybeFnOrVal::<fn()>::Val(_).

Both are completely sensible from a types POV.

Or in other words: Every F: Fn() -> _ is also a T: (with no bounds besides the implied Sized).

3

This is not a problem though? impl From<fn()> for MaybeFnOrVal<()> and impl From<fn()> for MaybeFnOrVal<fn()> are not conflicting, since, well, they are implementations on a distinct types. Problem is with blanket implementations only.

It might be a nonsensical, but it's possible now on nightly (upd: there was a link here, but I re-read the code and understood that it is not relevant here), so there have to be some mechanism to explicitly exclude this case.

1 Like
4

Ah yeah, I misread things, thanks.

5

It's technically allowed by the type system and you can create a type that satisfies this condition in nightly though.

6

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.