Make regular stdio lock() return 'static handles

[Mark-Simulacrum]

This also deletes the unstable API surface area previously added to expose this
functionality on new methods rather than built into the current set.

Closes #86845 (tracking issue for unstable API needed without this)

r? @dtolnay to kick off T-libs-api FCP

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

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!

See this document for info about what commands tagged team members can give me.

[rfcbot]

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

[tlyu]

I think it's great that this looks like it's going through. Thanks to everyone who worked on it. Given the amount of opposition I received when I tried to bring this up earlier as an alternative to #86845, I think it would be great to have somewhat more explanation (probably also linked to #86845) for why this approach is now acceptable in terms of API signature change.

[Mark-Simulacrum]

If you have a direct reference to the objections, that might help address them more directly. The primary objections I was able to locate amounted to possible future desires for a non 'static API, but given that stdio is inherently global and no strong design which prevents these from being added has been proposed, it seemed feasible to directly stabilize.

FWIW, part of the rationale here was also that it didn't seem of any benefit to stabilize 'static returning versions and not just change the lifetime bound here: we effectively make all of the same commitments but with a less ergonomic default API.

[joshtriplett]

@tlyu FWIW, I think one notable part of the objections were to the more complex approach of making the lock return a non-static lifetime but arranging to extend that lifetime to the scope of a binding via some kind of language change. That seemed like more complexity than we wanted, as well as raising potential compatibility questions. I would guess that that took some attention away from the simple approach of just making the lock 'static, in addition to non-specific concerns about closing off future avenues of changes we might want to make.

In general, we tend to be quick to make forwards-compatible changes that don't close off avenues for potential future development, and slow and cautious about making changes that do, even in the cases (like this one) where doing so might actually be the cleaner solution, and even when we don't have a particular future development in mind.

[tlyu]

If you have a direct reference to the objections, that might help address them more directly. The primary objections I was able to locate amounted to possible future desires for a non 'static API, but given that stdio is inherently global and no strong design which prevents these from being added has been proposed, it seemed feasible to directly stabilize.

FWIW, part of the rationale here was also that it didn't seem of any benefit to stabilize 'static returning versions and not just change the lifetime bound here: we effectively make all of the same commitments but with a less ergonomic default API.

Thanks. The most coherent objection I could find was https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/What.20does.20StdinLock.20borrow.20from.20Stdin.3F (also linked in #86845) which basically amounted to "nailing down the lifetime as 'static precludes possible alternative implementations in the future". I think that's unlikely, given that apparently, the reason that the current implementation uses a static mutex is that the suggested hypothetical future alternative implementation was already tried and rejected in favor of a static mutex. (See #77154.)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

❤️

[dtolnay]

@bors r+

[bors]

📌 Commit 398cccd has been approved by dtolnay