Implement Input for stdlib types that implement Display

[casey]

We talked about having a blanket impl of Input for things that implement Display, but there are lots of problems with that, so we sort of abandoned it.

It might still be nice, however, to have Input implementations for stdlib types that implement Display, so you can do things like pass numbers to commands.

What do you think of us just providing the impls?

We could do it with a macro, something like:

impl_input!(u8);
impl_input!(i8);
…

Or all in one item:

impl_input!(u8, i8, …);

[soenkehahn]

I think this is overall a good idea. But I'm hesitant to implement it right away without a concrete situation where someone wants this. For two reasons:

1. This does clutter the api documentation a bit. So if no-one ever wants to have an Input instance, there is a (small) advantage in not having it.
2. If we have a concrete use-case it's easier to come up with a perfect solution.

Did you find yourself in a situation where you wanted a particular Input instance? If yes, where did the value come from?

[casey]

I think that's fair. I don't have a particular use case, it just seems like something that would be nice. What do you think about leaving issues like this open? I tend to leave open issues with enhancements that I'm likely to implement, but don't yet have a plan to implement, but I have mixed feelings about whether that's a good idea or not.

I think the advantage here is that if someone wants this, they can add a comment, when otherwise they might not. The disadvantage is that it clutters the issues. I'm kinda torn.

[soenkehahn]

I would leave this open. People can then either chime in (ideally with a concrete use-case) or react with a thumbs-up (to the initial comment).

[soenkehahn]

I recently wanted to do something like this:

let bytes = 1024;
cmd_unit!(%"something -n", bytes);

I'm not sure this would have worked with any possible impls proposed in this issue. Because the type of bytes cannot be fully determined. Or would this have worked?

(Just leaving this comment here since I think the solution to this issue should take this into account.)

[casey]

I think it would actually work. Bare integers default to u32, so the impl for u32 woudl have been invoked. I tried it out, and this prints Hello, world!:

trait Foo {
    fn bar(self);
}

impl Foo for u32 {
    fn bar(self) {
        println!("Hello, world!");
    }
}

fn main() {
    100.bar();
}