История изменений

Ради выигрыша в тех редких случиев, когда строки будут чисто ascii

Хранить по 4 байта на символ не выгодно даже для русских и китайских букв, не только для ascii. А если хранить по 2 байта на символ (UTF-16), то интерфейс придется делать такой же как для UTF-8 (с вызовом функций) плюс оверхед по памяти для ascii, так что в двойне не выгодно.

Ну и конечно не выгодно конвертировать все строки туда сюда. Автор ripgrep недавно добавил поддержку UTF-16 для виндузятников, и так получается что на конвертацию кодировки уходит больше времени чем на сам поиск подстроки.

что произойдёт если попытаться взять срез строки

Срез строки берется в байтах. Если попытаться поделить строку на границе символа то произойдет panic. Но на деле всегда легко получить смещение в байтах для подстроки или нужного символа. Еще можно самому проверить границу если очень нужно.

вместо пары скобок придётся целую функцию набирать.

А в ассемблере все эти функции полностью инлайнятся, так что код получается очень эффективный.

Ради выигрыша в тех редких случиев, когда строки будут чисто ascii

Хранить по 4 байта на символ не выгодно даже для русских и китайских букв, не только для ascii. А если хранить по 2 байта на символ (UTF-16), то интерфейс придется делать такой же как для UTF-8 (с вызовом функций) плюс оверхед по памяти для ascii, так что в двойне не выгодно.

Ну и конечно не выгодно конвертировать все строки туда сюда. Автор ripgrep недавно добавил поддержку UCS-2 для виндузятников, и так получается что на конвертацию кодировки уходит больше времени чем на сам поиск подстроки.

что произойдёт если попытаться взять срез строки

Срез строки берется в байтах. Если попытаться поделить строку на границе символа то произойдет panic. Но на деле всегда легко получить смещение в байтах для подстроки или нужного символа. Еще можно самому проверить границу если очень нужно.

вместо пары скобок придётся целую функцию набирать.

А в ассемблере все эти функции полностью инлайнятся, так что код получается очень эффективный.