Fix semantics of `let _ = ...` not to drop

[MarkJr94]

fn main() {
    let x = ~5u;
    let _ = x;
    println!("{}", *x);
}

prints "5". I am under the impression that x should have been moved.

fn main() {
    let x = ~5u;
    let y = x;
    println!("{}", *x);
}

complains that x has been moved as expected

[alexcrichton]

cc @nikomatsakis, this is surprising!

[nikomatsakis]

that seems broken indeed. cc me.

[nikomatsakis]

Actually, thinking harder on this, I'm not sure it's broken. It depends on what we want the semantics of _ to be. Right now the semantics of _ patterns are inconsistent. We can choose between _ meaning: "drop this value" and _ meaning: "don't bind this value". I think we want the latter; in this particular case, that means that let _ = x; is just a no-op. (Note that today trans sometimes chooses "drop this value" and sometimes chooses "don't bind this value" -- in particular we treat let _ = ... totally different from let (_, _) = ...)

Here is an example to explain why I think we want _ to mean "don't bind this value":

fn some_func(pair: (~Foo, ~Bar)) {
    {
        let (ref x, _) = pair; // should this *really* free the second half of `pair`??
        ...
    }
    {
        let (_, ref y) = pair; // ...because then you couldn't do this latter...
    }
}

Nominating and adding to meeting agenda.

[nikomatsakis]

Updated title.

[pcwalton]

Decided that let _ always run at end of scope. Need implementation.

[pnkfelix]

P-backcompat-lang. (Pretty sure we discussed in a recent mtg.)

[nikomatsakis]

We settled on the semantics of _ meaning "ignore". I think
implementing this mostly means removing the special case code in
trans to perform a drop.

[emberian]

@nikomatsakis are you actively working on this? I want to take it.

[thestinger]

@nikomatsakis: So this means we want let _ = foo.lock(); to call the destructor at the end of scope, right? That's what I'd like, but I'm not entirely clear on what the decision was from what's written here.

[nikomatsakis]

@thestinger actually no, in that case foo.lock() represents a temporary, and hence the decision about when it would be freed depends on #3511. The current rules there that I am working are "end of statement". The main change is that if you do let _ = x (where x is an lvalue) then x is not freed immediately.

[glaebhoerl]

Would there be a drawback to making _ always behave the same as if you gave it a name?

[nikomatsakis]

@glehel yes. I described them here: #10488 (comment)

[thestinger]

@nikomatsakis: Ah, I was hoping that let _ = foo(); was just going to act like let _x = foo() without the need to name it.

[pnkfelix]

@nikomatsakis: I am trying to determine from the dialogue here whether the @thestinger -suggested semantics of having let _ = foo(); act like let _x = foo(); represents a third potential semantics, distinct from the two choices you outlined in #10488 (comment)

After considering the example you provided earlier, and rewriting it replacing occurrences of _ with named arguments, it seems like the _-is-_x semantics is indeed an instance of _ means "drop this value".

fn some_func(pair: (~Foo, ~Bar)) {
    {
        let (ref x, _arg) = pair; // It sounds like this moves ~Bar into _arg ...
        ...
                                  // ... which means we drop ~Bar here ...
    }
    {
        let (_, ref y) = pair;    // ... and thus makes this illegal
    }
}

(Update: after I wrote this I remembered that you cannot have a by-move and by-ref binding in the same pattern, so the above code couldn't work anyway. It seems like our current semantics must be inferring whether to treat _ as a by-ref or as a by-move depending on the rest of the pattern structure. Or maybe it is currently always by-ref, except for the special case of let _ = ...)

So if the above is correct, then I take it that if one wants to write with explicit names everywhere, eschewing _ (hypothetical company policy), then you would need to write the above like so:

fn some_func(pair: (~Foo, ~Bar)) {
    {
        let (ref x, ref _arg) = pair; // do not move ~Bar ...
        ...
    }
    {
        let (ref _ign, ref y) = pair; // ... and thus this is fine.
    }
}

@nikomatsakis is this consistent with your mental model?

(Note that I'm not asserting that _ should act like ref _arg; see aside below.)

---

An aside: The code transformation shown here did make me wonder if one could explain the new _ via a macro-desugaring (assuming some sort of gensym functionality), rather than saying "it is special no-op form". I was thinking of a pseudo-explanation like _ desugars into ref _fresh_var. But that is probably not correct, since I suspect it is not compatible with the R-value semantics assigned by #3511. So "desugars to ref _fresh_var" seems like third point in the design space. But this third alternative is probably not a very useful one because I anticipate nasty borrowck failures if one were to start having _ map to implicit references. (But then again, it might be closer to what @thestinger was expecting.)

[thestinger]

I think what I expected it to do is probably not a great idea, but is useful in a world of RAII locks and such.