###Important numbers:
inline-capacity on 64bit: 23 bytes
inline-capacity on 32bit: 11 bytes
It uses a few features (untagged_unions, alloc, heap_api, str_mut_extras, inclusive_range) and requires a recent nightly.
It uses the highest bit of the length field to distinguish between the inlined and "normal" state. So the length is limited to isize::MAX (2 GB on 32bit)
It could use more tests and documentation, and definitly needs a few reviews before it is safe to use in critical applications.
Yes, this would make the most sense. This is basically the the pre-RFC for this.
thought it would be better to write an implementation (that is as efficient as possible, without changing the size of the type) and see how much interest there is, before writing such a RFC.
Yeah, definitely - having something tangible to discuss is always better than talking in the abstract. I do, however, recall some github (IIRC) issues where SSO was discussed (and maybe even some proof of concepts were illustrated). I don't, however, know offhand where those conversations/ideas stand today.
`as_mut_vec' is indeed not possible, without changing the layout of Vec and making it dependent on the endianness. (the MSB of len needs to be at the end of the struct).
Right, thanks. I'll try to catch up on that rather long thread. Looking at the tail of it, though, indicates there's some resistance to doing SSO for String. Maybe that's right, I've not thought too deeply about it myself, and perhaps reading through that thread will make it clear(er).