Rfcs: Remove `option_from` feature

[botika]

Option implements an ultra generic converter that the only thing it does is wrap with a Some. This makes Option a special type in which no other conversion can be implemented.

That is to say that by not putting Some, we lose a lot of abstraction.

Could it be removed?

[RustyYato]

No, that would be a major breaking change, which is not an option.

This makes Option a special type in which no other conversion can be implemented.

That is to say that by not putting Some, we lose a lot of abstraction.

It's hard to tell what you mean by this, do you have an example of where From<T> for Option<T> was problematic?

[Lokathor]

If that From didn't exist for Option no one else would be able to define their own instead anyway, it's not blocking users from doing anything with their code.

[RustyYato]

@Lokathor with recent changes to the orphan rules, it possible to write that implementation (but I would find any other implementation surprising)

[burdges]

Another conversion would take the form impl From<S> for Option<T>, no? Into/From, or their Try variants rejecting values, altering values sounds quite counter intuitive.

[botika]

My case, simple rust expression evaluator https://github.com/botika/v_eval :

pub enum Value {
    Bool(bool),
    Float(f64),
    Int(i64),
    Str(String),
    Range(Range<i64>),
    Vec(Vec<Value>),
    None,
}

For all types I can implement TryInto, but for Option has conflict:

impl TryInto<Option<Value>> for Value {
    type Error = ();

    fn try_into(self) -> Result<Value, Self::Error> {
        match self {
            Value::None => Ok(None),
            v => Ok(Some(v)),
        }
    }
}

So I have to have 2 ways to convert from Value -> Rust type for call methods.

Also, it is not used. You can remove these lines https://github.com/rust-lang/rust/blob/master/src/libcore/option.rs#L1358-L1372 and run normally.

[RustyYato]

Even if it isn't used inside std, other crates may depend on it. I know I've written at least 1 crate thst depends on it. So we csnnot remove this implementation.

If you want some help finding alternative ways around this problem, go to users.rust-lang.org, I'd be happy to help there. (I'm Yato there).

[jonas-schievink]

Closing as this is a breaking change that can not be made.