Better temporary lifetimes (tracking issue for RFC 66)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#66: better temporary lifetimes.

Some unresolved questions to be settled when implementing:

1. This implies that the lifetimes of temporaries is not known until after typeck. I think this is ok but it is a phase change which can sometimes be tricky (currently temporary lifetimes are known before typeck).
2. We have to specify the precise rules over when a temporary is extended. There are various subtle cases to be considered:

• Clearly we must consider whether the parameter type is a reference with a lifetime that also appears in the return type. Does the variance in the return type matter? (I think: no, too subtle and not worth it.)
• When do we decide what the type of the parameter is? Do we consider the declared type, the type after inference, or a hybrid?

Some examples where this matters:

fn identity<T>(x: T) -> T { x }

// Are these the same or different?

foo(&3);
foo::<&int>(&3);

My take: Probably we should just consider the fully inferred type.

Unresolved questions

• Resolve the concern about semantic changes described in comment.

[jdm]

cc me

[killerswan]

I've got an example which seems related. Apparently as of 470dbef a let binding is necessary before a call to .as_slice() to keep it alive long enough to use in a function?

[schickling]

👍

[Stebalien]

Is there any reason we can't just rewrite:

foo().bar().baz(&bip().bop().boop())

as:

let mut tmp = foo();
let mut tmp = foo.bar();
{
    let mut tmp2 = bip();
    let mut tmp2 = tmp2.bop();
    let mut tmp2 = tmp2.boop();
    let mut tmp2 = &tmp2;
    tmp.baz(tmp2)
}

And let the optimizer do it's thing? Given that rust's move semantics, I can't see how this could cause any problems. This is just a sanity check; I'd be happy with a "no, it's complicated".

This would fix the write!(io::stdout().lock(), "{}", thing); case.

[nikomatsakis]

The thing is that destructors sometimes have side-effects (for
example, RefCell destructors). If we did the rewrite you suggested, at
least according to the current rules, it would mean that the
destrutors always execute at the end of the current block, more or
less, which is usually not what people want. The current rules are
mostly that temporary destructors end at the end of the current
statement, unless the temporary is being assigned into a let-bound
variable, in which case they live as long as the variable. (This is
roughly what C++ does as well.) The goal of this RFC was to be smarter
about knowing when the temporary will be assigned into a let-bound
variable.

On Wed, Mar 02, 2016 at 09:22:19AM -0800, Steven Allen wrote:

Is there any reason we can't just rewrite:

foo().bar().baz(&bip().bop().boop())

as:

let mut tmp = foo();
let mut tmp = foo.bar();
let mut tmp2 = bip();
let mut tmp2 = tmp2.bop();
let mut tmp2 = tmp2.bop();
let mut tmp2 = tmp2.boop();
let mut tmp2 = &tmp2;
tmp.baz(tmp2)

And let the optimizer do it's thing? Given that rust's move semantics, I can't see how this could cause any problems. This is just a sanity check; I'd be happy with a "no, it's complicated".

---

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

[Stebalien]

The goal of this RFC was to be smarter about knowing when the temporary will be assigned into a let-bound variable.

Assuming you mean "when a temporary would be referenced by a let-bound variable", I see why this is more complicated.

[vitiral]

I just want to leave my 2c that this is a very frustrating issue for newbies. I didn't think of myself as a newbie, having written two fairly stable libraries in rust, but today I was trying to write a memory manager for micro-controllers, learning about unsafe and PhantomData and all sorts of fun stuff -- all of which went great. Then, when I was ready to test my library I hit this compiler error which I had never seen before.

Thinking it was something I did with the internals, I began to question my entire way of doing things. Long story short it took me the better part of 4 hours to finally realize that nothing was wrong with my library. No -- what was wrong is that I hadn't put a let statement on every unwrap. I really feel like rust has left me down -- the behavior as-is is super unintuative.

I wish I had listened to the compiler better... maybe that is the lesson I really should learn here.

[brson]

@nikomatsakis What's the status of this issue?

[nikomatsakis]

@brson no change at all. But I've had it on my list of things to write up instructions for. In fact, I was just coming to take a stab at that.

[nikomatsakis]

OK, so, it's taking me a lot longer to prepare those instructions than I expected. In part this is because the original RFC is not very well specified. I've started a "amendment" (basically a rewrite) that both specifies the current behavior and tries to more precisely specify what RFC 66 should do. This will hopefully get done soon, you can see a draft here.

My basic plan (at a very high level) is to:

• step 1: convert the construction of the "extended temporary" tables into on-demand
  • I hope that typeck doesn't need these results; I think they are only needed by borrowck, but I have to verify
• step 2: have that construction also demand the signatures of functions that are called and the typeck tables, so that we can find out what methods are being called
  • if that doesn't work, a bit more refactoring will be needed
  • if it does work, we should be able to use that to compute the temporary tables easily enough...