Temporary lifetime extension through tuple struct and tuple variant constructors

[m-ou-se]

This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as Some().

Before:

let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended

After:

let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended

So, with this change, this works:

let a = Some(&String::from("hello")); // New: String lifetime now extended!

println!("{a:?}");

Until now, we did not extend through tuple struct/variant constructors (like Some), because they are function calls syntactically, and we do not want to extend the String lifetime in:

let a = some_function(&String::from("hello")); // String not extended!

However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.

In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.

This needs a lang fcp.

---

More examples of what will work after this change:

let x = Person {
    name: "Ferris",
    job: Some(&Job { // `Job` now extended!
        title: "Chief Rustacean",
        organisation: "Acme Ltd.",
    }),
};

dbg!(x);

let file = if use_stdout {
    None
} else {
    Some(&File::create("asdf")?) // `File` now extended!
};

set_logger(file);

use std::path::Component;

let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!

assert_eq!(path.components.first().unwrap(), c);

[rustbot]

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[m-ou-se]

Does this count as 'I-lang-easy-decision'? I think it might be an easy decision.

[lcnr]

please add an explicit test for

let indir = Some;
let x = indir(&temp);

[traviscross]

Happy to implement a demo implementation of that so we can play with it and try out what the consequences are.

We have more unlikely things than this as experiments. I'd say do it, and let's see how it feels.

[RalfJung]

had some arguments against that. (Mostly that you won't be able to tell at the call site, I think.)

That argument already applies to this proposal though: you can't tell if it's a tuple struct constructor or a function call. So I feel we're crossing that line already with the proposal at hand.

[lcnr]

That argument already applies to this proposal though: you can't tell if it's a tuple struct constructor or a function call. So I feel we're crossing that line already with the proposal at hand.

In theory, in practice convention + lints mean that it is not ambiguous: constructors are upper case, functions are not.

[nikomatsakis]

I've given this some thought. I'm in favor.

@rfcbot reviewed

But I do want to be clear about something... @traviscross wrote

We have more unlikely things than this as experiments. I'd say do it, and let's see how it feels.

...but I had the impression this was an insta-stable change. At least, I don't see any feature-gate-dependent code in the diff (and I don't know why we would need an FCP otherwise).

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

In principle this could use an RFC. Seems a bit like overkill to me though.

[nikomatsakis]

@rustbot labels +relnotes

[m-ou-se]

We have more unlikely things than this as experiments. I'd say do it, and let's see how it feels.

...but I had the impression this was an insta-stable change. At least, I don't see any feature-gate-dependent code in the diff (and I don't know why we would need an FCP otherwise).

@nikomatsakis That wasn't about this PR. That was about a tangent: having an attribute on function parameters for temporary lifetime extension. (See the comment right before the one you quoted.)

The change in this PR is insta-stable, yes.

[Nadrieril]

LGTM impl-wise, just one test suggestion.

[Nadrieril]

Given that this is like a stabilization, could you check if the Reference has enough detail about lifetime extension that it would need to be updated for this change? Apart from that, I think r=me with the extra test once the FCP completes.

[RalfJung]

Yeah the reference has a section on that at https://doc.rust-lang.org/nightly/reference/destructors.html#temporary-lifetime-extension

[traviscross]

@rustbot labels +S-waiting-on-documentation

[m-ou-se]

Reference PR: rust-lang/reference#1813

(It's a submodule, so not part of this PR.)

[Nadrieril]

Looks good, r=me once FCP completes.

[traviscross]

@rustbot labels +S-waiting-on-documentation

Thanks for the PR to the Reference. However, we hold off merging the stabilization until the Reference PR is reviewed and ready to merge, so we keep this label until then.