Skip to content

detect when "unconstrained type parameters" could be provided explicitly to a fn call #40015

Closed
@nikomatsakis

Description

@nikomatsakis
Contributor

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:

fn foo<T>() { }

fn main() {
    foo();
}

It'd be nice to suggest that the user write foo::<T> for some explicit T. 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:

fn foo<T>() -> Option<T> { }

fn main() {
    let x = foo();
}

Should we suggest labeling x: Option<T> or foo::<T>? This case is borderline, but if you replace Option 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:

fn foo<T, U>() -> T { }

fn main() {
    let x: i32 = foo();
}

Here we know T, but not U. Should we suggest foo::<_, XXX>? How do we phrase the XXX 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?

Activity

added
A-diagnosticsArea: Messages for errors, warnings, and lints
C-enhancementCategory: An issue proposing an enhancement or a PR with one.
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Feb 21, 2017
cengiz-io

cengiz-io commented on Feb 21, 2017

@cengiz-io
Contributor

Hello @nikomatsakis

I'll be working on this.

Thanks again!

estebank

estebank commented on Feb 21, 2017

@estebank
Contributor

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>()`
   |
nikomatsakis

nikomatsakis commented on Feb 22, 2017

@nikomatsakis
ContributorAuthor

This note in particular makes my eyes glaze over:

   = note: type annotations or generic parameter binding required

Let's definitely remove that one. :)

added a commit that references this issue on Dec 13, 2019

Auto merge of #65951 - estebank:type-inference-error, r=nikomatsakis

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.WG-diagnosticsWorking group: Diagnostics

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @cengiz-io@nikomatsakis@estebank

      Issue actions

        detect when "unconstrained type parameters" could be provided explicitly to a fn call · Issue #40015 · rust-lang/rust