Support larger inline strings

[ParkMyCar]

With the recent advancements in const generics, it's theoretically possible to support a CompactString with a user defined size that is > 24, e.g. 32, 40, 48 bytes long. We should try doing this and playing with an API

[CAD97]

The way to do so would be to switch Repr (back) to a (*mut (), [MaybeInit<u8>; N], NonMaxU8) layout. However, this N probably wants to be { max(CONFIGURED_INLINE_SIZE, 24) - size_of::<*mut ()>() - size_of::<NonMaxU8>() }, so still requiring const dependent types (which aren't stable yet) or typenum to polyfill.

Typenum supports lifting and lowering to/from plain const generics, so the API can still be pure const generics even if the implementation uses typenum to do math to them.

[Kijewski]

Maybe the other direction would be possible, too? 16 bytes with the capacity on the heap.

[NobodyXu]

Maybe the other direction would be possible, too? 16 bytes with the capacity on the heap.

Nah, I don't think this is a good idea.

That would make CompactString incompatible with String.
Conversion from String or to it would have to take extra time to realloc/rewrite the layout.

It would also impact ToCompactString implementation, which also relies on O(1) conversion from String.

[stepancheg]

It might be useful to have something like CompactStr type which is 16 bytes and compatible with Box<str>.

[ParkMyCar]

Coming back to this, my time should be freeing up soon, and I was thinking about how to further improve compact_str. What I think makes the most sense is to work on first is this and #264.

I plan to put together a proposed design/"next steps" soon which will cover additional variants like CompactStr or CompactPath and would love any and all thoughts, I'll update this thread when it's written :)

[NobodyXu]

Coming back to this, my time should be freeing up soon, and I was thinking about how to further improve compact_str. What I think makes the most sense is to work on first is this and #264.

Good to hear, I really want #264 to be done and I thought about implementing it myself, but I am a bit busy recently so not enough time for this.

I plan to put together a proposed design/"next steps" soon which will cover additional variants like CompactStr or CompactPath and would love any and all thoughts, I'll update this thread when it's written :)

For CompactPath, I think it might make sense to first implement unix::CompactOsStr, which can contain arbitrary byte and windows::CompactOsStr, which contains utf-16.

Once they are ready, compact_str can trivially define CompactOsStr and then CompactPath.

Even if it fails, it would still have some usable types for further investigation/experiments.