Ergonomic Suggestion for Option Arguments

[jsouto18]

Hey,
While using this library I felt like it could benefit ergonomically from changing the signature of two functions:

pub fn set_fg(&mut self, color: Option<Color>) -> &mut ColorSpec {
    // ...
}
pub fn set_bg(&mut self, color: Option<Color>) -> &mut ColorSpec {
    // ...
}

Changing them to:

pub fn set_fg(&mut self, color: impl Into<Option<Color>>) -> &mut ColorSpec {
   let color = color.into()
   // ...
}
pub fn set_bg(&mut self, color: impl Into<Option<Color>>) -> &mut ColorSpec {
   let color = color.into()
   // ...
}

This would allow for developers, using this library, to configure a ColorSpec struct like this:

ColorSpec::new().set_fg(Color::Red);

Rather than:

ColorSpec::new().set_fg(Some(Color::Red));

This would also be backwards compatible, meaning that any case of .set_fg(Some(Color::Red)) would still be valid.

I would be happy to make a PR if you decide that this would be beneficial for the library.

Thank you!

[BurntSushi]

I understand why you're making this suggestion, but I've never been a huge fan of the impl Into<Option<...>> trick. I generally don't like its implicitness and find that it makes the call sites more difficult to read.

I'm not totally opposed to it though. I'll noodle on it. If you want to put up a PR, that would be great!

[Property404]

Consider also, you could have a Color::None or Color::Default or whatever variant. That way, you wouldn't have to deal with Options anymore. You get the ergonomic benefit of doing ColorSpec::new().set_fg(Color::Red), while maintaining a simple (actually, simpler) function signature