utf-8 в языке нет. Есть только CHAR/симв8, UTF-16 (UCS-2), изображаемый сейчас записью из одного поля и UTF32 = симв32. Но при этом utf-8 сплошь и рядом служит для связи с внешним миром, поэтому "попа есть, а слова нет" - сплошь и рядом массив из симв8 на самом деле закодирован в utf-8. Деться от него абсолютно некуда, и если его убрать, то будет выбор либо выкинуть кириллицу, либо использовать кодовые страницы. В принципе было бы неплохо иметь тип, который явно подчёркивает, что данная строка является корректным utf-8, тогда можно было бы много сделать более надёжным или быстрым, но это нет и я этого делать не собираюсь. utf32 тоже уже есть - на нём сделан весь "богатый текст", более того, объекты представлены символом с кодом 0FFFFFFFFH (-1), которого в юникоде нет. utf16 нужен для обмена с Windows в режиме приложения. Т.е. я ничего не добавляю в язык, кроме того, что в некоторых случаях превращаю число цел32, которое на самом деле буква utf32, в тип симв32, про который явно сказано, что это литера, а не число. Здесь особого усложнения по сравнению с ББ нет, просто взято не 16 бит, а 32 - возможно, это и ошибка, но не моя, поскольку не я писал модуль Texts в A2. Если бы я для своих задач попытался бы сделать симв16 = CHAR из ББ, в текстах символы продолжали бы оставаться числами, что не есть слишком плохо, но тем не менее весьма коряво, и главное, я не смог бы пользоваться инфраструктурой модуля Texts (а это все текстовые редакторы и прочее) для своей деятельности без перекодировки строк из 16 бит в 32, что тоже глупо.
В т.ч. и литералы utf-8 уже присутствуют в системе в огромном количестве. А литералы utf32 нужны, чтобы писать всякие процедуры для работы с текстом, например, в каком-нибудь парсере текста, читаемого из окна редактора (для IDE), они нужны для ключевых слов.
Вот конкретный пример:
https://gitlab.com/budden/ja-o-s/-/blob/опять-симв32/source/BimboScannerUCS32.Mod#L580
Код:
просей ch.UCS32CharCode из
| UCS32u.PropisnajaN: Identifier(s);
если strЭто(Лит32("НУЛЬ")) то s := nil всё
| UCS32u.StrochnajaA: Identifier(s);
если strЭто(Лит32("аесли")) то s := elsif
аесли strЭто(Лит32("адресВПамяти")) то s := address
всё
| UCS32u.StrochnajaV: Identifier(s);
если strЭто(Лит32("в")) то s := in
аесли strЭто(Лит32("возврат")) то s := return
аесли strЭто(Лит32("воплощает")) то s := implements
аесли strЭто(Лит32("всё")) то s := end
аесли strЭто(Лит32("выходя")) то s := finally
всё
За счёт истинных литералов, зашитых в компилятор, получается существенный выигрыш в скорости, и другим путём его достигнуть нельзя (ну разве только переделать весь алгоритм).
Но в общем-то вопрос явно устарел, я уже сделал тип симв32 (он есть только в ЯОС, в A2 его так и не осилили доделать и выкинули), сделал литералы строк этого типа, Лит32, которые и хранятся в программе в формате UTF32, ЛитСимв32, представляющий литеру UTF32 (представлен 32-разрядным числом, но для компилятора это отдельный тип симв32, изолированный от численных типов) и поправил вылезшие ошибки компиляции штуках в 20 файлов, теперь в модуле Texts литера в объекте "текст" изображается именно литерным типом, а не числовым, как раньше. Последствия - например, при отладке можно будет видеть текст, а не числа. Это не является необходимым, но это удобно. И собственно, тут обсуждать уже особо нечего, можно поосуждать, но я просто даю обратную связь по тому, к чему я пришёл в результате обсуждения.