compact_str VS smol_str

Not that I know of! As part of compact_str v0.6 we tried to make the API of CompactString 1:1 with String, inevitably we missed a few (1, 2, 3) things but they were fixed in this latest release.

... and more! Please see the CHANGELOG for more detail

(See the compact_str implementation as an example.)

Along with performance improvements, this release includes implementing multiple methods for CompactString, to bring its API nearly 1:1 with String. The only exception being methods that don't have a direct port for a small string optimization, e.g. into_bytes, or methods that aren't yet stable. A full change log can be found here.

Doing this has been on the back of my mind for a while, just filed an issue to track this! #119

There's a draft pr for this.

Here're a few projects I considered interesting (including my own project) and relatively easy to participate: - pushgen Push-style design pattern for processing of ranges and data-streams. - compact_str A memory efficient immutable string type that can store up to 24* bytes on the stack - openssh-rs Scriptable SSH through OpenSSH in Rust - pegasus A multi-node parametrized command runner with a focus on simplicity - concurrent_arena Container that can have elements insert/removed concurrently and uses a 'u32' as key.

I wrote something similar to compact_str, but it is: - a Box when on the heap - (so clone is O(n)) - (but still immutable) - 2 usizes in size

Here you go: https://github.com/ParkMyCar/compact_str

I have a similar sentiment to u/matklad regarding this: https://github.com/rust-analyzer/smol_str/pull/37

Comparatively: * SmolStr can inline up to 22 bytes but does not adjust down for 32-bit architectures, meaning it's potentially wasting memory on 32-bit archs. Similarly though it's immutable and Clone is O(1) * SmartString can inline up to 23 bytes, but it's mutable and Clone is O(n). Also this crate makes assumptions about the memory layout of a String, which in theory should be fine, but is a slight caveat.