Skip to content

Error message usage of _ is unclear #21042

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

Closed
mdinger opened this issue Jan 12, 2015 · 9 comments
Closed

Error message usage of _ is unclear #21042

mdinger opened this issue Jan 12, 2015 · 9 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mdinger
Copy link
Contributor

mdinger commented Jan 12, 2015

Error messages use _ a lot but it's meaning is never explained. This could be improved.

Playpen

fn test(o: Option<i32>) {}

fn main() {
    let i = 7;
    test(i);
}

Error:

// What is `_` supposed to mean? Apparently integral value but it still seems meaningless...
... error ... expected `core::option::Option<i32>`, found `_`  ... found integral variable)
<anon>:5     test(i);
                  ^
error: aborting due to previous error

6/8/2017: updated error message:

error[E0308]: mismatched types
 --> <anon>:5:10
  |
5 |     test(i);
  |          ^ expected enum `std::option::Option`, found integral variable
  |
  = note: expected type `std::option::Option<i32>`
             found type `{integer}`

error: aborting due to previous error
@kmcallister kmcallister added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 12, 2015
@mdinger
Copy link
Contributor Author

mdinger commented Feb 15, 2015

The book is getting a note which seems related: #22293

@steveklabnik
Copy link
Member

Triage: no change.

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@Mark-Simulacrum
Copy link
Member

Nominating for discussion. What do we expect _ to mean? Ideally we'd get a decision on that and then see if we follow that throughout the code; but at least a consensus on the first would be good.

I believe the current state is that _ is an inference variable that we couldn't elaborate to anything more specific.

@nikomatsakis
Copy link
Contributor

In the particular case of this example, we now print {integer}:

rustc 1.17.0 (56124baa9 2017-04-24)
error[E0308]: mismatched types
 --> <anon>:5:10
  |
5 |     test(i);
  |          ^ expected enum `std::option::Option`, found integral variable
  |
  = note: expected type `std::option::Option<i32>`
             found type `{integer}`

error: aborting due to previous error

@nikomatsakis
Copy link
Contributor

Currently, _ is used to mean (roughly) "some type we've not inferred yet". Perhaps we could use this {} convention for that? e.g., {TBD}?

@nikomatsakis
Copy link
Contributor

I will say that we've been back-and-forth on this point a lot. the primary advantage of _ here is that it can be copied-and-pasted into user's code and has roughly the same meaning ("infer this"). However, we have many types where that cannot be done (including {integer}), so I'm not sure how important of a principle that really is.

@mdinger
Copy link
Contributor Author

mdinger commented Jun 8, 2017

FWIW, I think the it is definitely better than it used to be. I'm not sure what {} is though.

@nikomatsakis
Copy link
Contributor

@mdinger it's not anything, that's the point. :) It's just a way for us to insert "meta" stuff.

@nikomatsakis
Copy link
Contributor

I'm inclined to close this issue, absent a particular suggestion. The specific case in question has been improved and we don't know how to do much better. In any case, we have existing issues with more discussion, hence closing as a duplicate of #25633 and #40985.

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 T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants