Hi!
So I am unsure if this is a bug (in my understanding it is 馃榿): When using a type parameter for a function (to assert a certain trait to be implemented), and then using an "optional box" instead of an optional trait object, the compiler somehow doesn't see that None was passed and wants/needs to infer the type for the parameter. However since Option is an enum with its type parameter only on Some, this type inference shouldn't happen?
The use case is quite simple:
Serde's Serialize trait has a type parameter and therefore can't be a trait object, which is why a type parameter on the calling function has to make sure that serde can serialize whatever is passed in. erased_serde unfortunately seems to have grown stale? It's for the CrateDB driver to avoid breaking the interface by having to specify a type explicitly...
https://github.com/celaus/rust-cratedb/blob/dev/src/lib.rs#L217-L221
I tried this code:
trait T {
fn m<S>(&self, s: S);
}
fn f<X: T>(t: Option<Box<X>>) {
println!("well");
}
fn main() {
f(None);
}
I expected to see this happen:
I expected this code to compile, since Option is an enum and None doesn't have a type parameter ?
Instead, this happened:
/p/t/t{} 馃悙 cargo run
Compiling t v0.1.0 (file:///private/tmp/t)
error[E0282]: unable to infer enough type information about `X`
--> src/main.rs:10:5
|
10 | f(None);
| ^ cannot infer type for `X`
|
= note: type annotations or generic parameter binding required
error: aborting due to previous error
rustc --version --verbose:
rustc 1.15.1 (021bd294c 2017-02-08)
binary: rustc
commit-hash: 021bd294c039bd54aa5c4aa85bcdffb0d24bc892
commit-date: 2017-02-08
host: x86_64-apple-darwin
release: 1.15.1
LLVM version: 3.9
There's no bug. Option has a type parameter, and None is a variant of Option. Even though you passed None, the compiler has to know what concrete type X you aren't passing in order to generate a correct implementation (monomorphization) of the function. You can fix it by writing None::<Box<Foo>> where Foo is some struct that you've implemented T for.
@durka Thanks! It won't be the most elegant solution but it will work 馃憤
Most helpful comment
There's no bug.
Optionhas a type parameter, andNoneis a variant ofOption. Even though you passedNone, the compiler has to know what concrete typeXyou aren't passing in order to generate a correct implementation (monomorphization) of the function. You can fix it by writingNone::<Box<Foo>>whereFoois some struct that you've implementedTfor.