Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Foo::<> does not use type parameter defaults #36980

Closed
bluss opened this issue Oct 5, 2016 · 4 comments
Closed

Foo::<> does not use type parameter defaults #36980

bluss opened this issue Oct 5, 2016 · 4 comments
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@bluss
Copy link
Member

bluss commented Oct 5, 2016

This is about the stable Rust feature that types can have type parameter defaults.

Example code below. I expected that if Test::<T>::method specifies one type parameter, and leaves the second to the defaulted, that Test::<>::method should leave both type parameters to be defaulted. Instead it is equivalent to Test::method (both type parameters inferred).

#[derive(Default)]
pub struct Test<X = String, Y = String> {
    x: X,
    y: Y,
}

fn main() {
    // both explicit
    let s = Test::<f32, f32>::default();

    // use default for second
    let t = Test::<i32>::default();

    // use default for both? 
    // error[E0282]: unable to infer enough type information about `_`
    let u = Test::<>::default();

    // This uses the default for both.
    let u2 = <Test>::default();
}

playground link

@petrochenkov
Copy link
Contributor

This works as expected right now, but the rules are... counterintuitive.
Basically <Test>, Test (aka Test::<>) and Test::<A, B, C> use different rules - 1) defaults are used, nothing is inferred, 2) everything is inferred, defaults are not used 3) defaults are used, nothing is inferred.
I hope this can be fixed somehow by using inference and falling back to defaults, but any inaccurate step from the current rules is a breaking change unfortunately.
@eddyb should know more details.

@bluss
Copy link
Member Author

bluss commented Oct 5, 2016

@petrochenkov Ok, I'm reminded that ::<> is valid on all types, I had forgot about that. Maybe this issue is a bit silly! It's still surprising that one can't reach the all defaults case using the regular path syntax.

@eddyb
Copy link
Member

eddyb commented Oct 5, 2016

::<> is a noop, not sure if it should be or not. It is quite silly either way 😞.

@steveklabnik steveklabnik removed the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Mar 10, 2017
@steveklabnik steveklabnik added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Mar 23, 2017
@steveklabnik steveklabnik added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed A-docs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 26, 2017
@steveklabnik
Copy link
Member

Closing in favor of rust-lang/reference#24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants