[snip]

you can relatively easily find out how many bytes a string takes up with std.utf. You can also iterate by code points or graphemes there if you want to translate some kind of character index to byte position.

HOWEVER it's not clear what a character is. Sure for the posted cases here it's no problem but when it comes to languages based on combining glyphs together to form new glyphs it's no longer clear what is a character. There are Graphemes (grapheme clusters) which are probably the closest to what everybody would think a character is, but IIRC there are edge cases with that a programmer wouldn't expect, like adding a character not increasing the count of characters of the string because it merges with the last Grapheme. Additionally there is a performance impact on using Graphemes over simpler things like codepoints which fit 98% of use-cases with strings. Codepoints in D are mapped 1:1 using dchar, take up to 2 wchars or up to 4 chars. You can use std.utf to compute byte lengths for a codepoint given a string.

I would rather suggest you support FixedString with types other than char. (wchar, dchar, heck users could even use any arbitrary type and use this as array class) For languages that commonly use more than 1 byte per codepoint or for interop with Win32 unicode APIs, JavaScript strings, C# strings, UTF16 files in general, etc. programmers might opt to use FixedString with wchar then.

With D's templates that should be quite easy to do (add a template parameter to the struct like struct FixedString(size_t maxSize, CharT = char) and replace all usage of char in your code with CharT in this case)

[snip]

One minor usability issue I found just glancing over the code: many of your methods take char[] as argument. Generally, you want const(char)[] instead, so that it will work with both char[] and immutable(char)[]. No reason why you can't copy some immutable chars into a FixedString, for example.

[snip]
Another issue is the way concatenation is implemented. Since FixedStrings have compile-time size, this potentially means every time you concatenate a string in your code you get another instantiation of FixedString. This can lead to a LOT of template bloat if you're not careful, which may quickly outweigh any benefits you may have gained from not using the built-in strings.

oh dear, that doesn't sound good. i hadn't considered that at all. i'm not sure how to even begin going about fixing that...