We do have higher-ranked trait bounds but they currently only work for lifetimes. If they worked for type parameters you could do something like this:
fn f<G>(g: G) where G: for <A: Read> FnOnce(A) {
if false {
g(File::open("foo").unwrap());
} else {
g(Cursor::new(b"foo"));
}
}
However, this fails with a compile error:
error: expected `>` found `A`
where G: for <A: Read> FnOnce(A)
^
I don't know if the closure expansion is actually capable of generating fully generic closures even if this did work. It's probably on the table of features to implement one day, likely as part of the broader Higher Kinded Types initiative.
Automatically implementing Foo for closures would require the same higher-kinded polymorphism, AFAIK, so that's not really possible either.
You can get runtime polymorphism with trait objects:
// You only need FnOnce since you don't use the closure more than once.
// And you can omit the `-> ()` the same as you can on functions.
fn f<G: FnOnce(&mut Read)>(g: G, pred: bool) {
if pred {
g(&mut File::open("foo").unwrap());
} else {
// Notice the argument to `Cursor::new()` changed a bit,
// that's because `b"foo"` is actually `&[u8; 3]`, which does not implement `Read`.
// It won't coerce to `&[u8]` (which does implement `Read`) in this position
// so we need to make the conversion explicit.
g(&mut Cursor::new(&b"foo"[..]));
}
}
However, this adds overhead due to dynamic dispatch (since the concrete Read impl has to be discovered at runtime). If you're not worried about being the fastest you can be, this overhead is probably negligible for your application. It's just something to keep in mind if you run into performance bottlenecks later on.