ACP: std::ffi::c and std::ffi::os submodules · Issue #134 · rust-lang/libs-team (original) (raw)

Proposal

Note: this ACP will reference the std crate and submodules of it, although in cases where types are also available in core, equivalent modules should also be added there as well.

Problem statement + Motivation, use cases

(It's difficult to separate these two, so, I combined them into one section for this ACP.)

As part of rust-lang/rust#104353 (ACP: #135), I mention that adding a Bytes iterator type to std::ffi could potentially be ambiguous, since both C strings and OS strings could theoretically offer one. This problem exists for any iterators or other types added adjacent to C strings and OS strings that could be potentially ambiguous.

There is precedent for this among other standard library types, since essentially all collection and sequence types have their own submodule so they can be paired with their iterators. Even std::option and std::result exist for this purpose, since otherwise these modules would only contain the types Option and Result respectively.

Solution sketches

The recommendation of this ACP is to add std::ffi::c and std::ffi::os modules, although std::c_str and std::os_str could technically be added as an alternative.

Proposed moves:

To ensure backwards-compatibility, use self::{c::{CStr, CString}, os::{OsStr, OsString}} would be added into std::ffi to re-export the moved items.

This would be similar to how, for example, std::collections::BinaryHeap is just a re-export of std::collections::binary_heap::BinaryHeap, although there are still types only included in std::collections::binary_heap like std::collections::binary_heap::Iter.

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.