Implement From<T> for Option<T>

[abonander]

impl From<T> for Option<T> {
    fn from(val: T) -> Self {
        Option::Some(val)
    }
}

This is a trivial impl and I think it would help ergonomics in certain areas of API design. As an example, consider a method on a fictional I/O wrapper for setting a timeout:

struct Socket;

impl Socket {
    // Set the timeout, in seconds. Removes timeout if `None`.
    fn set_timeout<T: Into<Option<u64>>(&mut self, timeout: T) { /* .. */ }
}

This can be called in both of the following forms without needing separate methods for u64 and Option<u64>:

let mut socket = Socket;

socket.set_timeout(3600);
socket.set_timeout(None);

Currently, if this API wanted to take an Option<u64>, it would have to be invariant over it:

fn set_timeout(&mut self, timeout: Option<u64>);

Requiring Some everywhere:

socket.set_timeout(Some(3600));

I think the above is much cleaner.

There are existing APIs such as the following:

http://doc.rust-lang.org/nightly/std/net/struct.UdpSocket.html#method.set_read_timeout

which I think could be migrated relatively seamlessly. I think the only breakage would be if someone was referring to them by UFCS, so the addition of a type parameter would break resolution (maybe). A Crater run would probably help here.

Otherwise, I don't see much as far as downsides go, except maybe some brief confusion for newbies. However, I don't think it would take them long to realize, "Oh! It can take u64 or Option<u64>. Cool!" Then it's just another neat little feature of Rust. I don't think accidental conversions would be a problem, either.

[ticki]

The main objection, I can see, is that you'll now have multiple ways of converting T to Some(T). But generally, I'm in favor of using From more.

[Stebalien]

👍 This is actually pretty cool.

[killercup]

This looks pretty convenient!

The only issue I can see is that APIs will be harder to read, just compare

fn set_timeout(&mut self, timeout: Option<u64>);

and

fn set_timeout<T: Into<Option<u64>>(&mut self, timeout: T);

(But that's probably something that rustdoc could be optimised for.)

[abonander]

The ergonomics could be improved with an alias of some sort, like IntoOpt<T>, to drop one pair of angle-brackets and a few letters. Something like:

type IntoOpt<T> = Into<Option<T>>;

[killercup]

That reads a bit nicer, @cybergeek94, but doesn't really solve the problem that the significant type information is no longer part in the function's argument as the T is defined either before or after (with where) the argument list.

(IntoOpt reads weird. I don't have a better suggestions, though. Except, if you want to troll people coming from Haskell: Call it MaybeOption<T>! 😉)

[abonander]

I don't know if it's that big of an issue, at least for most intermediate to advanced users. Whenever I see a type parameter in documentation or code, my eyes instantly jump to the type parameter list to find its definition, and then to the where clause to see if there's anything more.

[ticki]

I, too, don't think that's a problem. You quickly get used to it.

[killercup]

I didn't mean to imply it's a big issue, just something to be aware of. Beginners are often confused by the notion of Option itself, so Into<Option<T>> can be quite confusing. If we were to add this and use it in more APIs, I'd expect it be mentioned in the docs in a few places.

In general, I'm in favour of this addition.

[abonander]

@killercup If we did go with the trait alias, we could have additional documentation on it saying what it is for, so they could click the link in Rustdoc output and instantly find out how it's supposed to work.

[BlacklightShining]

Not an objection or anything…but, in case no one's noticed, this basically gives Rust (opt-in) nullable types.

[Stebalien]

@BlacklightShining shh.... 😶

[BlacklightShining]

@Stebalien I'm conflicted, actually. On the one hand, set_timeout(3600) and set_timeout(None) read really well. On the other, I liked the explicitness that Some() provides…

The decrease in readability is also something to consider. Did we already decide against allowing traits there? fn set_timeout(&mut self, timeout: Into<Option<u64>>) seems better to me than the alternative using currently-available generics syntax.

[killercup]

Coming back to this after two weeks, I'm still in favour of this. While it makes designing the API a bit more complicated for library authors, it makes the code using the API pretty nice to read and write. I think it works pretty good for people coming from languages with null-able types: You can pass None only to certain functions (as defined by their argument types) and the compiler/type system ensures that you deal with the nullability.

Other than that, I've been searching for APIs where this would be useful (i.e., functions that actually take Option<T>), but after looking in std, time, and hyper, I could only find read_timeout, which is already @cybergeek94's example above. (It seems to me that most APIs that work on structs with optional fields tend to use the builder pattern.)

What are some other APIs where this would be useful?

[kamalmarhubi]

@killercup

What are some other APIs where this would be useful?

There are a few APIs in nix that could benefit. We aim to take Option<&T> in the wrapper for any system API parameter that is a nullable pointer. Some examples:

• mount(2)
• splice(2)
• mq_open(2)

[bluss]

@kamalmarhubi Does it need to be the Into trait? You could use another trait for the same effect.

[codyps]

@bluss is there a reason you're concerned about the use of the Into/From trait?

[bluss]

Changes to From/Into impact everyone's API design (also preexisting APIs) so it needs close scrutiny.

Using the same From/Into traits for everything just means we risk having conflicts down the line when independently convenient conversions clash. A specific trait seems more in line with Rust's explicitness and may even be an easier to understand API.

fn ping<T>(host: &str, timeout: T) where T: Optional<i32> {  }
// where both i32 and Option<i32> implement Optional<i32>.

[kamalmarhubi]

@bluss there's no strong reason, and I'd be open to something like Optional. It was mostly in keeping with the conversion traits RFC's motivation:

The motivation is to remove the need for ad hoc conversion traits (like FromStr, AsSlice, ToSocketAddr, FromError) whose sole role is for generics bounds.

[notriddle]

Not an objection or anything…but, in case no one's noticed, this basically gives Rust (opt-in) nullable types.

The problem with nullable types is handling them once you have them. Needing to convert a type into its optional version explicitly doesn't really help anything, except that Into<Option<Option<T>>> is kinda confusing. How should calling a function with that has that type (probably because of generics or macros assembling it) behave?

[BlacklightShining]

@notriddle You can pass a T, an Option<T>, or an Option<Option<T>>. It's up to whoever wrote|generated the function to decide (and then document) how that argument is interpreted.

[ticki]

https://github.com/search?l=rust&q=%22asoption%22+language%3ARust&type=Code&utf8=%E2%9C%93

[kamalmarhubi]

@BlacklightShining

You can pass a T, an Option<T>, or an Option<Option<T>>. It's up to whoever wrote|generated the function to decide (and then document) how that argument is interpreted.

I don't think you'd be able to pass T to something accepting Into<Option<Option<T>>. There's the blanket impl From<T> for T, and the inverting impl<T, U> Into<U> for T where U: From<T>, but I don't see anything transitive like impl<T, U: From<T>, V: From<U>> From<T> for V which would be necessary for it to work.

[tshepang]

Can this now be closed?