String implementations are low enough level that they get influenced quite a bit by memory management behavior, sometimes in surprising ways. G++ used to have

String implementations are low enough level that they get influenced quite a bit by memory management behavior, sometimes in surprising ways. G++ used to have CoW strings, but I believe they dropped them because for common cases the atomic reference counting was more expensive than potential copying. Inlining strings save space and allocator traffic at the expense of a more complex string implementation and (depending on the platform/implementation) strings that do not start word aligned. There are other flags you might want to put on an underlying text sequence: - that the text is exclusively ASCII in UTF-8 strings. This means the character count and indexing can be optimized to constant-time operations - latin-1 in UTF-16 strings. This means you can do an alternate 8-bit encoding for space savings, as well as constant-time count/indexing. - mark that the string represent a single grapheme cluster (aka a printable character). This may allow you to combine unicode text processing to a single data structure. - mark that the representation is a slice. In this case, you'd typically store an offset rather than a capacity. This again helps you combine higher level types on top of a single data structure and text processing libraries. These features (and especially combinations of them) impact the hot path for text processing. If your language is already doing custom allocation (such as using a copy constructor), the allocator savings are nil, so it becomes a space vs code trade-off.