Goal:
- Easier to prototype
- Improves usability for new-to-rust users
- Still allow optimizing hot loops
- Easy interop either calling into other crates or being called into
Non-goals:
- Stable-enough API for being used in a crate's "1.0" API. There will be enough policy and moving pieces that I expect the major version to be bumped once a year at least.
For use cases, requirements, and feature ideas, see https://github.com/rust-lang-nursery/cli-wg/issues/26 and https://github.com/rust-lang-nursery/cli-wg/issues/10
High level features
- Bytes type
- String type
- Path type
- Python breadth of functions, including
Pull in from other crates:
Guidelines
When to pull in a crate
- If the use case is common enough
- If it integrates in to be first-class (e.g. globs being a function on path)
- Or if it is obscure enough that we deem it important to improve visibility
- Or it is small enough that it the justification for adding it for one-off is small (e.g. boolinator)
Open Questions
Should we include regex and how should we expose it?
Should we include anything else from stdx
Goal:
Non-goals:
For use cases, requirements, and feature ideas, see https://github.com/rust-lang-nursery/cli-wg/issues/26 and https://github.com/rust-lang-nursery/cli-wg/issues/10
High level features
EZString's interning approach for allocating for'staticor have an internal enum of theArcand'static, like Create rust graph library with nitric #2EZStringPull in from other crates:
.ok()forCommandGuidelines
When to pull in a crate
Open Questions
Should we include regex and how should we expose it?
Should we include anything else from stdx