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);

[joshtriplett]

This seems great to me. As you said, we already do this for struct constructors in general, except tuple struct constructors. This is a consistency improvement and a usability improvement.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot reviewed

This sounds right to me. We earlier decided #138458 partly on the basis that we see Some(x) as simple syntactic sugar for Some { 0: x }¹, and this I think goes along well with that.

It does make me think, though, that maybe we also should have an attribute that authors can apply to function parameters to opt-in the corresponding arguments to temporary lifetime extension. I'm thinking here about how many new constructors that mostly just pass through their inputs into the output ADT really want this same behavior for the same reasons we want it for Some(..). But we can take that up another day.

Footnotes

1. Though there, it was in pattern position. ↩

[m-ou-se]

It does make me think, though, that maybe we also should have an attribute that authors can apply to function parameters to opt-in the corresponding arguments to temporary lifetime extension.

Yup, I've suggested exactly that a few times, but @nikomatsakis had some arguments against that. (Mostly that you won't be able to tell at the call site, I think.)

If we had that, and also a way to do an unsafe call without an unsafe block, I believe we wouldn't need super let at all for pin!() and let f = format_args!(..);.

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

[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.