using unused arguments

[jesse99]

Seems to me if an argument is marked unused (with an underscore) then there should be a warning or error if it is actually used. For example the below compiles and runs just fine:

// rustc --test ignores1.rs && ./ignores1
use std;

fn make_five(_x: int) -> int
{
    _x + 5
}

#[test]
fn tester()
{
    assert make_five(1) == 5
}

[bstrie]

Historically I believe the underscore doesn't signify "this variable is unused" so much as it means "don't bother me for not using this variable". It's true that nowadays we have #[allow(unused_variables)] (or whatever) for the latter, but I'm still not sure if the meaning of the underscore should change in this way.

[jesse99]

Code is not just for communication with the compiler though. Arguably it's at least as important to communicate with other programmers (or yourself six months from now). If _x means that _x is not used then the intent of the code is very clear and, even better, enforced by the compiler. If it merely means that warnings or errors are suppressed then not only can readers not rely on the intent, but they can easily become actively misled.

[catamorphism]

Nominating for maturity milestone 1 (well-defined)

[Aatch]

On 2013-04-29 16:26:37, Jesse Jones wrote:

Code is not just for communication with the compiler though. Arguably it's at least as important
to communicate with other programmers (or yourself six months from now). If _x means that _x is not
used then the intent of the code is very clear and, even better, enforced by the compiler. If it
merely means that warnings or errors are suppressed then not only can readers not rely on the

intent, but they can easily become actively misled.

Reply to this email directly or view it on GitHub:
#3423 (comment)

Having it be enforced (as in throw an error) would impact macros that generate functions, since the contents of the function may not be used, but it's not known to the macro author.

[bstrie]

@jesse99 I'm of the opinion that if you really don't want your variable to ever be used, name it as a single underscore so that it cannot ever be referred to. Also, leaving around unused variables seems like a code smell. For example, if you have for range(0,10) |_i| {, you really ought to be doing for 10.times { instead.

[bstrie]

To illustrate my first point, this compiles:

fn main() {
    make_five(1);
}

fn make_five(_: int) -> int
{
    5
}

But you can't ever use the variable:

fn main() {
    make_five(1);
}

fn make_five(_: int) -> int
{
    _ + 5  // error: unexpected token: `_`
}

[jesse99]

Well like I said before readability is important. And _options is a hell of a lot easier to grok than _.

Not sure that I'd agree that unused variables are a code smell. They can easily happen with trait implementations where only some need to use certain arguments. And also during development when the code dealing with some argument isn't written yet.

[pnkfelix]

I agree with bstrie (i.e., that _foo denotes, to me, "Lint: do not bother me about how I do or do not use _foo."), and would be happy if this bug were closed as "not-a-bug"; but its a decision the team should make, not just me.

[graydon]

just a bug, removing milestone/nomination.

[bstrie]

The use case for this seems sufficiently narrow that I'm comfortable closing this bug. I suggest that you merely ignore the variable entirely by binding it to _.