From the point of view of users of this string type, I’d be inclined to argue that the deterministic nature of the current implementation is
Re: signedness of an implementation detail: (It seems to be that nature of c++ that minor details catalyse the most momentous arguments) It seems to me that: * degski has a point that there may be some conceptual efficiency gain by removing the unsigned restriction * this would necessarily mean that the overall size of the static_string’s memory footprint becomes implementation defined (since the inplementor may now choose either a signed 16 bit word to represent the length of a string with capacity 128 rather than an 8 bit word. preferable. My recommendation (for what it’s worth) is to ship as is, and if it can be shown that there is a problem with this approach, raise an issue in the GitHub repo with a real world example of a problem caused by the current specification and evidence of how a switch to signed internal size solves this. R -- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212