Maciej Hirsz

We already have `const_fn` feature which requires nightly, so if we can put this behind a feature flag (same or a new one) I'd be happy to accept a PR.

On non-64 bit arch `beef::lean::Cow` is just a re-export of `beef::Cow` so there is no need to do anything on user end, which I reckon is what should be documented...

Sadly neither `PathBuf` or `OsString` exposes `*_raw_parts` methods, or any way to get a byte pointer or some such, so this has to sit on the backburner until std is...

The only such type that can correctly map it is `OsStr`/`OsSTring`. The [`os_str_bytes`](https://crates.io/crates/os_str_bytes) crate might be of some use here, will have to dig in further.

No, the `Container` here would be able to arrange stuff in whatever order it wants. Currently lean version is (ptr, len) with capacity put into higher 32 bits of len,...

No, capacity is only used: + When you call `into_owned`. + When the `Cow` is cloned. + When the `Cow` is dropped. Most of what you want to do with...

The keys are sorted into a tree, but the tree will be balanced differently depending on insertion order, so hashes would differ. If you are fine with matching objects with...

NaN on `Number` is here purely for conversions from `f64`. I'm okay with it being removed (along with `From`) as long as there is a conversion from `f64` for `JsonValue`...

If your strings are short they will be inlined on stack and use `JsonValue::Short` instead of `JsonValue::String`. That said, the next big release of the crate will remove the `Short`...

Current `Object` is preserving insertion order, which seems to be a thing most people expect. Will make a note to add it to the docs.