Skip to content
New issue

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

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

Already on GitHub? # 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

# for free to join this conversation on GitHub. Already have an account? # 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