Making imap::client::Client a trait?

[cyphar]

At the moment I'm trying to use this library for some personal tools. One thing I would really like to do is to write a function that "sets up" a client. However (and pardon me if I'm not understanding the problem correctly -- I'm still quite new to Rust) as far as I can tell, there isn't a nice way for me to currently write a function that can return either an encrypted client struct (imap::client::Client<TlsStream<TcpStream>>) or an unencrypted client struct (imap::client::Client<TcpSream>). I believe this is because imap::client::Client is a struct and not a trait (so I cannot write a function that returns a trait object).

Is it reasonable to make imap::client::Client a trait? I'd be happy to work on this myself, but I thought I'd ask first because it's possible what I'm suggesting is not a good Rust practice.

[jonhoo]

Welcome to Rust! We could have a trait that is implemented by all clients, though I'm hesitant to introduce one as it would be a backwards-incompatible change. Users would now need to import the trait everywhere, and we'd need to introduce a new way of creating clients. One alternative that might work for you is to have two different methods for creating clients, and then write your other methods as generic, like so:

use std::io::prelude::*;
fn with_client<T: Read + Write>(c: &mut Client<T>) {
}

When #58 is merged, which is already a backwards-incompatible change, we might consider adding this change though. @mattnenterprise might have thoughts. Keep in mind that using a trait object everywhere (which is what you'd have to do if you want to return the trait) does have some performance overhead, though in this particular case the overhead is likely negligible compared to that of doing network requests.

[jonhoo]

I really don't know what to do about this. I suspect we don't actually want to make Client a trait, as instead whatever thing you have that uses a Client<T> should just be generic over T. Do you have a particular more complete use-case in mind that we can look at?

[cyphar]

I haven't looked at this in a long time, so feel free to close it.