Make regular stdio lock() return 'static handles by Mark-Simulacrum · Pull Reque...

rfcbot commented 12 days ago •

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

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 commented 9 days ago

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

tlyu commented 9 days ago

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 commented 9 days ago

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 commented 9 days ago •

@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 commented 9 days ago

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