Regression: shared_ufmt removed and no way to format into SharedStr without heap allocation

[chabapok]

Hi,

I’m migrating from flexstr 0.9.2 to 0.11.0 and noticed a couple of regressions related to formatting and inline storage size.

1. Removal of shared_ufmt/local_ufmt

In 0.9.2 there was a method shared_ufmt, which (as I understood and relied on) allowed formatting into SharedStr without heap allocation, as long as the resulting string fit into the inline buffer.

In 0.11.0, shared_ufmt no longer exists, and I can’t find an alternative way to format directly into SharedStr while avoiding heap allocation for short strings.

Question:
What is the recommended way in 0.11.0 to format into SharedStr without using the heap, when the formatted string is short enough to fit inline?

2. Inline string size is no longer configurable

In older versions it was possible to control the inline buffer size by defining a custom type, for example:

type BigInlineStr = FlexStr<64, /* other params */>;

This was very useful for performance-critical code where stack-only storage is important.

In 0.11.0, the inline size appears to be hardcoded inside the library, and users can no longer choose a custom inline capacity.

Question:
Is this an intentional design decision?
If so, what is the recommended approach for users who need a larger inline buffer and want to avoid heap allocations?

[nu11ptr]

It is intentional in the sense that the new version of FlexStr is a complete rethink/rewrite from scratch and I haven't gotten to that part yet. I am 95% happy with the design (a few tweaks incoming, but minor) unlike 0.9 and prior versions, so the foundation is very solid. That said, its use cases currently are more limited and a bit changed (it focuses more on the inevitable cohabitation with String and efficient back and forth via box string), and unfortunately there is no way (currently) to format a new string off heap. You can certainly reclaim that allocation if under 22 chars by optimizing, but there will be an allocation to start. I WOULD like to add formatting and other string manipulation back at some point, and have started looking at the code, but not sure when I will get to it. For me, it is a nice to have at the moment. If that changes, its priority will change. Sorry I don't have a better answer.

Btw, this technically is mentioned on the front page, but perhaps it isn't clear. If you have lingo suggestions I am open to that.

Users of previous versions: you should be aware this new version is a ground up rewrite with a solidly different thought process, API and design. Even if the previous versions didn't match your needs, this one might. Users should be aware that nearly all the string construction code is not yet present in this version. The new way to do this (workaround?) is to do the work as a String and then import it into a LocalStr or SharedStr. Moving into and out of the boxed variant (from_owned) should be near zero cost.