Type parameter default not respected with enums

[sfackler]

enum Foo<S = i32> {
    Bar,
    Baz(S)
}

fn f<S>(_: Foo<S>) {}

fn main() {
    f(Foo::Bar);
}

~ ❯ rustc test.rs
test.rs:9:5: 9:6 error: unable to infer enough type information about `_`; type annotations required [E0282]
test.rs:9     f(Foo::Bar);
              ^
error: aborting due to previous error

[sfackler]

This may actually just be "RFC 213 hasn't been implemented yet". Any idea, @nikomatsakis?

[apasel422]

Item 2 from RFC 213 hasn't been implemented yet, so default type parameters aren't used as fallbacks for inference. The same issue occurs with structs:

use std::marker::PhantomData;

struct Foo<T = ()>(PhantomData<T>);

fn f<S>(_: Foo<S>) {}

fn main() {
    f(Foo(PhantomData));
}

> rustc foo.rs
foo.rs:8:5: 8:6 error: unable to infer enough type information about `_`; type annotations required [E0282]
foo.rs:8     f(Foo(PhantomData));
             ^
error: aborting due to previous error

CC #21939.

[gkoz]

Is this the same or different issue?

fn foo<T = i32>(x: Option<T>) { }

fn main() {
    foo(None)
}

<anon>:4:5: 4:8 error: unable to infer enough type information about `_`; type annotations required [E0282]
<anon>:4     foo(None)
             ^~~

[sfackler]

I believe that's the same issue.

[IvanUkhov]

Here is another context where default values could be useful:

trait Foo {
    fn foo() -> Self;
}

impl Foo for f32 {
    fn foo() -> f32 {
        42.0
    }
}

impl Foo for f64 {
    fn foo() -> f64 {
        42.0
    }
}

fn bar<T: Foo=f64>() -> T { // “=f64” has no effect.
    T::foo()
}

fn main() {
    let _: f64 = bar(); // The type annotation is still needed.
}

Regards,
Ivan

[jroesch]

I currently have a PR open that implements default type parameter fallback, if anyone is so inclined any test cases would be appreciated. PR: #26870

[steveklabnik]

Triage: still true today

[nikomatsakis]

I feel like this is expected behavior at the moment. At least until we settle the story around default type parameter fallback, which is more the purview of #27336. I'd be inclined to close this myself.

[Mark-Simulacrum]

Closing as expected behavior per @nikomatsakis's comment.