Stabilize from_raw_os feature in 1.1 #25125
Conversation
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
|
This would not make it into 1.0, even if merged. See https://internals.rust-lang.org/t/reminder-the-trains-are-running/1959 Generally speaking, stabilizing large amounts of code like this requires an RFC. @aturon , what do you think? |
I know, this is a request to merge and cherry-pick into 1.0.
Sorry, I thought this was covered in the IO reform RFC but, on further inspection, it appears to have been removed. |
|
@Stebalien I basically agree with the rationale that you laid out, especially given that these functions are unsafe in any case (due to memory safety issues around e.g. memory maps). I will discuss the stabilization situation with @alexcrichton. |
|
OK, I discussed this with @alexcrichton, and we feel comfortable stabilizing these as of 1.1.0, but not backporting to 1.0 (given the still-recent change to unsafe). Would you mind updating the PR accordingly? |
|
Done (I left the feature as from_raw_os). I can also go through the usual RFC process if you would prefer given that 1.1.0 ~7 weeks from now. |
Stebalien
changed the title
|
For each trait itself could you also add a |
|
Done. |
So, I realize this is really late in the game so it's unlikely to be accepted but `FromRawFd`/`FromRawHandle` are necessary for fine grain control over file creation. For example, the current `OpenOptions` does not provide a way to avoid file creation races (there's no way to specify `O_EXCL` or the windows equivalent). Stabilizing these traits and their implementations will give 1.0 users fine-grain control over file creation without committing to any new complex APIs. Additionally, `AsRawFd`/`AsRawHandle` are already stable so I feel that that stabilizing their inverses is a reasonably small change. Disclaimer: I'm asking because my crate, tempfile, depends on this feature.
So, I realize this is really late in the game so it's unlikely to be accepted but
FromRawFd/FromRawHandleare necessary for fine grain control over file creation. For example, the currentOpenOptionsdoes not provide a way to avoid file creation races (there's no way to specifyO_EXCLor the windows equivalent). Stabilizing these traits and their implementations will give 1.0 users fine-grain control over file creation without committing to any new complex APIs. Additionally,AsRawFd/AsRawHandleare already stable so I feel that that stabilizing their inverses is a reasonably small change.Disclaimer: I'm asking because my crate, tempfile, depends on this feature.