Skip to content

ACP: std::ffi::c and std::ffi::os submodules #134

Closed

Description

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:

  • std::ffi::CStr => std::ffi::c::CStr
  • std::ffi::CString => std::ffi::c::CString
  • std::ffi::CStrBytes (Tracking Issue for CStr::bytes rust#112115) => std::ffi::c::Bytes
  • std::ffi::OsStr => std::ffi::os::OsStr
  • std::ffi::OsString => std::ffi::os::OsString

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.

Links and related work

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    ACP-acceptedAPI Change Proposal is accepted (seconded with no objections)T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard libraries

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions