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.

[m-ou-se]

rust-lang/reference#1813 is ready. (Just waiting for this PR to be merged, so the code test passes.)

[ehuss]

I have removed the S-waiting-on-documentation label. I think this should be ready to merge per #140593 (comment).

[m-ou-se]

@bors r=Nadrieril

[bors]

📌 Commit 855ea48 has been approved by Nadrieril

It is now in the queue for this repository.

[traviscross]

As just a note for our possible later analysis, it's interesting to analyze, actually, why this is (conjecturally) not a new SemVer hazard.

I'd mostly expect for this,

pub struct W<T>(pub T);

and this,

mod outer {
    #[allow(dead_code, hidden_glob_reexports, non_snake_case)]
    fn W() {} //~ For namespace masking.
    pub use self::inner::*;
    mod inner {
        pub struct W<T>(pub T);
    }
}
pub use outer::W;
#[allow(non_snake_case)]
pub fn W<T>(x: T) -> W<T> {
    W { 0: x }
}

to be equivalent and indistinguishable today. If they were, then this PR would mean that you newly couldn't switch from the first to the second, e.g. to do additional work in the constructor, without a breaking change.

As it is, though, it'd already be breaking, as we disallow using the tuple form in patterns when the constructor (in the value namespace) isn't in scope. So with the first form, let W(_) = W { 0: () } works, while it doesn't for the second.

Probably, actually, I find that a bit surprising. In pattern position, I think of the tuple struct syntax W(_) as simple sugar for the W { 0: _ } form, and so probably I wouldn't expect what's in scope in the value namespace to matter. This model of tuple struct syntax in pattern position came up as well in:

• type privacy: Check constructor types in tuple struct patterns #138458