On a somewhat related note, I noticed that the string structure no longer has extra padding bytes available, so adding new string types (substring) is not possible without increasing it's size
As it turs out, by shrinking the size_shift field to 2 bits there are 6 bytes left for types instead of the previous 2. So now a lot of new allocation types could be added, in theory.
I created the substring type on a branch, it does help with the naive cut-prefix-of-string buffer code case, at least. :)
Making size_shift a bitfields add an compiler-generation &3 to each access of it, more or less. This could cause a noticeable general slowdown, I have not checked if this is the case.
With patch:
string s = random_string(1024*1024); set format bench lambda(string s){while(strlen(s))s=s[1..];}(s);
Compilation: 549ns, Execution: 83.55ms
Without patch:
Compilation: 505ns, Execution: 35.16s
So, for 1Mb it's 400+ times faster. Of course, it's the ordo that is faster, the actual string_slice substring generation code is somewhat slower (for small values of 'somewhat').