Tracked by #375.
Problem
std::fs::file currently exposes wrapper names such as fs_open and fs_close while read-all operations still require caller-managed buffers. This is a useful low-level foundation but is not yet a clear user-facing filesystem API.
Scope
Define the portable std::fs surface separately from std::sys::fs and std::io::fd.
Consider:
- Names that do not repeat the fs module namespace unnecessarily.
- Explicit names for path-based and descriptor-based operations.
- read_into and read_to_end style distinctions instead of ambiguous read_all naming.
- File metadata, directory, rename, copy, and removal operations.
- Buffer ownership and allocation contracts.
- Integer error behavior until runtime variants can be lowered.
- A future migration path to Result-based APIs without requiring it in this issue.
Completion criteria
Tracked by #375.
Problem
std::fs::file currently exposes wrapper names such as fs_open and fs_close while read-all operations still require caller-managed buffers. This is a useful low-level foundation but is not yet a clear user-facing filesystem API.
Scope
Define the portable std::fs surface separately from std::sys::fs and std::io::fd.
Consider:
Completion criteria