eztd ("Easy Standard') or nonstd Library

[epage]

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 'static or have an internal enum of the Arc and 'static, like Create rust graph library with nitric #2
• 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/
• 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() for Command
• 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

[epage]

https://crates.io/crates/text_io is tempting depending on error handling

[epage]

text_io has at least some option for error handling but the license is non-standard.

[epage]

There is now https://github.com/BurntSushi/bstr

[epage]

These comprehensions look promising
https://crates.io/crates/py-comp