-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
detect when "unconstrained type parameters" could be provided explicitly to a fn call #40015
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-diagnostics
Working group: Diagnostics
Comments
nikomatsakis
added
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Feb 21, 2017
Hello @nikomatsakis I'll be working on this. Thanks again! |
Current output: error[E0282]: type annotations needed
--> $DIR/xxx.rs:xx:xx
|
14 | let x: i32 = foo();
| ^^^ cannot infer type for `U`
|
= note: type annotations or generic parameter binding required Some options: error[E0282]: type annotations needed
--> $DIR/xxx.rs:xx:xx
|
14 | let x: i32 = foo();
| ^^^ cannot infer type for `U`
|
= note: type annotations or generic parameter binding required
= note: generic parameter `U` needs to be specified for foo::<T, U>() error[E0282]: type annotations needed
--> $DIR/xxx.rs:xx:xx
|
14 | let x: i32 = foo();
| ^^^ cannot infer type for `U`
| |
| you can specify the generic parameter here using `foo::<_, U>()`
|
= note: generic parameter `U` needs to be specified for `fn foo::<T, U>() -> T` error[E0282]: type annotations needed
--> $DIR/xxx.rs:xx:xx
|
14 | let x: i32 = foo();
| ^^^ cannot infer type for `U` in `fn foo<T, U>() -> T`
| |
| specify `U` using `foo::<_, U>()`
| |
This note in particular makes my eyes glaze over:
Let's definitely remove that one. :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-diagnostics
Working group: Diagnostics
Building on #39361, we might want to consider when users should add explicit type parameters to a fn call. I am imagining an example like this:
It'd be nice to suggest that the user write
foo::<T>
for some explicitT
. This will require a bit of thought:When do we want to suggest this in preference to annotating a local variable? I'd prefer to attach the annotation on the local variable, but maybe not if the type of the local variable is some complex thing that mentions the uninferred type deeply inside of it, whereas annotating the function would allow us to specify the uninferred type directly.
An example:
Should we suggest labeling
x: Option<T>
orfoo::<T>
? This case is borderline, but if you replaceOption
with some more complex type it tilts the balance further.What do we do when the fn takes many types, and we know them partially? We side-stepped the problem before of what to do when we have some information but not all. But it feels like here it may be more important. An example:
Here we know
T
, but notU
. Should we suggestfoo::<_, XXX>
? How do we phrase theXXX
to indicate to the user that this is the thing they need to provide?cc @cengizio -- interesting in pursuing?
cc @estebank @jonathandturner -- thoughts on how to phrase?
The text was updated successfully, but these errors were encountered: