Tracking Issue for OpenOptionsExt::as_flags

[FedericoPonzi]

This is a tracking issue for the OpenOptionsExt::as_flags method defined in #76110
The feature gate for the issue is #![feature(open_options_ext_as_flags)].

This feature was reverted in #77090

Steps

• Adjust Documentation
• Stabilization PR (see instructions on rustc-dev-guide)

Implementation history

• Implementing OpenOptionsExt::as_flags - Function to convert OpenOptions to c_int #76110

Adding non-default items to public traits like this is a breaking change. In particular, async-fs (part of smol) now no longer compiles on nightly because it impls std::os::unix::fs::OpenOptionsExt on its local newtype of std::fs::OpenOptions.

async-std appears to use the same approach and would thus also be affected. tokio only dodges the bullet because it defines its own tokio::fs::os::unix::OpenOptionsExt rather than use std.

It's hard to see how this could ever be stabilised in its current form.

[Darksonn]

We actually discussed this in Tokio on the PR for our OpenOptionsExt. tokio-rs/tokio#2515 (comment)

Update: async-fs (part of smol) now defines its own extension traits rather than implementing those from std.

[joshtriplett]

Attempting to revive this:

If we haven't already, we should make an attempt to seal OpenOptionsExt, assuming we can do so without widespread breakage.

If we can seal it, we can then add this method. If we can't, we'll have to add a new sealed trait for it.