Open
Description
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
- Wrap bytes?
- String type
- Something like easy_strings
- Data model: either take
EZString's interning approach for allocating for'staticor have an internal enum of theArcand'static, like Create rust graph library with nitric #2
- Data model: either take
- Something like easy_strings
- Path type
- Similar to
EZString - Possibly have a delay load parsed out version to make those operations faster?
- https://crates.io/crates/relative-path
- https://www.reddit.com/r/rust/comments/ibbv4t/short_post_using_long_paths_in_windows_and_rust/
- Similar to
- Python breadth of functions, including
- Strings have encode functions and guess-encoding
- Native interning support (if we go with Create rust graph library with nitric #2 approach)
- Path has glob support
Pull in from other crates:
- failure
- rayon
- boolinator
- assert_cmd's
.ok()forCommand - maplit: https://docs.rs/maplit/1.0.1/maplit/
- collect_mac for cases not covered by maplit: https://docs.rs/collect-mac/*/collect_mac/index.html
- itertools
- lazy_static
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