Design: Обсуждение: WebAssembly, Unicode и веб-платформа

Возможно, несколько потенциальных решений, которые я собрал из офлайн-отзывов, для рассмотрения:

Отдельный WTF-16

В Типах интерфейсов определите:

string   := list char
string16 := list u16

Определите принуждение, применяемое во время связывания, в следующих случаях:

| От | К | Ожидание
| ------------ | ------------ | -------------
| string | string16 | Перекодировать из UTF-8 в UTF-16
| string16 | string | Перекодировать из WTF-16 в UTF-8 (вариант замены)

Принуждение гарантирует, что модуль string16 работает на хосте WASI, соответственно, что модуль string и string16 могут взаимодействовать друг с другом, даже если оба модуля string и string16 модуль или хост вызывают один и тот же экспорт string или string16 , что в противном случае было бы неоднозначным.

Это также вносит двусмысленность в веб-встраивание, поскольку передача list u16 в JS может стать Uint16Array или DOMString . Принуждение всего JS от Uint16Array к DOMString кажется нежелательным, но на тип JS можно намекнуть, явно используя псевдоним string16 (с собственным двоичным идентификатором string16 :> list u16 является чисто семантическим там, где это необходимо) вместо list u16 в модуле адаптера. Отсюда и псевдоним. В этом случае string16 станет DOMString а list u16 станет Uint16Array .

Я не особо привязан к имени string16 и мне было бы хорошо с любым другим именем или любой альтернативой, которая не требует имени / идентификатора для устранения двусмысленности.

Оптимизация типа list.is_canon здесь не требуется, поскольку можно использовать list.count . Кроме того, дверь к UTF-any и потенциальной оптимизации Latin1, как показано ниже, можно оставить открытой, зарезервировав место на будущее в инструкциях адаптера list.*_canon .

UTF-любой

В Типах интерфейсов определите:

list.lift_canon $unit [...]
list.is_canon $unit [...]
list.lower_canon $unit [...]

where the $unit immediate is
  0: 8-bit (UTF-8, ASCII-compatible)
  1: 16-bit (UTF-16)
  2: 32-bit (UTF-32)
  3: 8-bit (Latin1, narrow UTF-16)

Это потенциальное решение можно рассматривать там, где требуется правильная форма. Это позволило бы избежать накладных расходов на двойное перекодирование и косвенного воздействия на размер кода, но не решает суррогатную проблему. Обратите внимание, что $unit 1-3 могут быть добавлены после MVP в качестве дальнейших оптимизаций, или мы можем сразу начать с некоторых из них.

WTF-любой

В Типах интерфейсов определите:

list.lift_canon $unit [...]
list.is_canon $unit [...]
list.lower_canon $unit [...]

where the $unit immediate is
  0: 8-bit (WTF-8, ASCII-compatible)
  1: 16-bit (WTF-16)
  2: 32-bit (Code points except surrogate pairs)
  3: 8-bit (Latin1, narrow WTF-16)

Это потенциальное решение также потребует переопределения char из скалярных значений Unicode в кодовые точки Unicode, при этом ограничивая списки char чтобы они не содержали суррогатных пар (но разрешали изолированные суррогаты), потенциально принудительно выполняемые при подъеме. Опять же, конкретные $unit в MVP спорны.

Сам по себе это не приводит к потерям, поэтому все остальное действительно становится просто оптимизацией после MVP.

Встроенный W / UTF-any

В типах интерфейса определите:

• Поднимите «список кодовых точек Unicode, изменяющих суррогатные пары», но опустите «список скалярных значений Unicode». Это нефункциональное изменение дизайна, когда оно применяется только во время 16-битного подъема.
• Добавьте необязательный параметр passthrough при опускании, чтобы получить «список кодовых точек Unicode». Это функциональное дополнение, обеспечивающее сквозную передачу без потерь.

Таким образом мы достигаем:

• Правильная форма по умолчанию
• Кодирование без потерь для языков WTF в качестве опции
• В сочетании с https://github.com/WebAssembly/interface-types/issues/136#issuecomment -861799460: встроенные кодировщики для большинства (всех?) Языков, которые мы хотим хорошо поддерживать.

IIUC, основная проблема заключается в том, что ИТ-отделы хотят, чтобы строки были последовательностями кодовых точек Unicode, но некоторые языки рассматривают строки как последовательности значений i8 или i16, которые могут соответствовать или не соответствовать правильно сформированным строкам Unicode. Одно простое решение будет иметь языки / API , которые принимают или производить недействительные строки Юникода использовать (list u8) или (list u16) (возможно , с некоторыми хороший псевдоним , как byte_string общаться умысел) , а не тип IT string , который IIRC является псевдонимом для (list char) . Обсуждались ли где-нибудь компромиссы в этом случае?

Я думаю, что проблема немного более тонкая, поскольку ИТ-отдел хочет определить char как «Скалярные значения Unicode», в которых есть дыра там, где будут суррогатные кодовые точки, и как таковые не могут представлять изолированные суррогаты. . WTF, с другой стороны, является «кодовыми точками Unicode» без этого ограничения, но последовательности ограничены тем, чтобы не содержать пар суррогатных кодовых точек (они будут заменены дополнительными кодовыми точками> U + FFFF, в то время как изолированные суррогаты допустимы). Вы это имели в виду?

Помимо этого, я думаю, что строки байтов типа C в const char* которые могут быть чем угодно, еще не обсуждались. Хотя, возможно, я это пропустил.

Одно простое решение будет иметь языки / API , которые принимают или производить недействительные строки Юникода использовать (list u8) или (list u16) (возможно , с некоторыми хороший псевдоним , как byte_string общаться умысел) , а не тип IT string , который IIRC является псевдонимом для (list char) .

В настоящее время я тоже предпочитаю это решение - тип wtf16string будет псевдонимом для (list u16) точно так же, как string в настоящее время определяется как псевдоним для (list char) . Значение псевдонима IIUC состоит в том, что результат функции, возвращающей (list u16) вызванной (например) JS, будет отображаться как список JS (чисел), тогда как результат функции, возвращающей wtf16string можно указать в виде строки JS.

Добавление дополнительного псевдонима wtf16string к черновику канонического ABI кажется относительно ненавязчивым.

WTF, с другой стороны, является «кодовыми точками Unicode» без этого ограничения, но последовательности ограничены тем, чтобы не содержать пар суррогатных кодовых точек (они будут заменены дополнительными кодовыми точками> U + FFFF, в то время как изолированные суррогаты допустимы).

Ах, означает ли это, что WTF-8 не то же самое, что простой (list u16) потому что у него есть это ограничение на добавление? Я не оценил этот нюанс. Моя интуиция подсказывает, что было бы излишним иметь как тип string представляющий последовательности правильно сформированных скалярных значений Unicode, так и тип wtf16string который почти является (list u16) но имеет дополнительные ограничения. Будет ли использование псевдонима для неограниченного (list u16) работать достаточно хорошо для систем, которые не обеспечивают правильного формата Unicode? Это примечание в спецификации WTF-8 предполагает, что это так.

Ах, означает ли это, что WTF-8 не то же самое, что простой (список u16), потому что у него есть это ограничение на добавление?

В нем говорится: «Подобно тому, как UTF-8 искусственно ограничен текстом Unicode, чтобы соответствовать UTF-16, WTF-8 искусственно ограничен, чтобы исключить пары суррогатных кодовых точек, чтобы соответствовать потенциально неправильно сформированному UTF-16». Iiuc, он обрабатывает их аналогично тому, как UTF-8 обрабатывает слишком длинные или усеченные байтовые последовательности. WTF-8 может представлять любой (list u16) , но не каждый (list u8) является допустимым WTF-8.

Будет ли использование псевдонима для неограниченного списка (список u16) достаточно хорошо для систем, которые не обеспечивают правильную формулировку Unicode?

WTF-16 сопоставляет 1: 1 случайным значениям u16 и это просто зависит от того, как эти значения интерпретируются, так что да, (list u16) будет работать.

IIUC, WTF-8 - это не совсем то же самое, что и произвольный list u8 . Например, запрещены «байтовые последовательности суррогатных пар» (см. Здесь ).

Однако WTF-16 _is_ то же самое, что и list u16 . Немного странно, что у них общая тема именования.

РЕДАКТИРОВАТЬ: должен был обновиться :)

Я опубликовал первый вопрос / ответ, посвященный только вопросу о суррогатах в интерфейсных типах / # 135 . Я думаю, что это старший бит, и, если мы сможем с этим согласиться, последующее обсуждение поддержки одного или нескольких форматов кодирования будет проще.

Спасибо, Люк.

Если вы захотите поддержать «Отдельный WTF-16», как указано выше (принуждение имеет решающее значение для обеспечения доступа к API-интерфейсам WASI и взаимодействия с JavaScript без связующего кода), я буду чувствовать себя комфортно с предложенным char диапазон значений. У языков WTF-16 будет выход, который им необходимо интегрировать, так же как и с модулями, написанными на том же языке, JavaScript и посредством замены языками UTF- *. Я бы также чувствовал себя намного лучше насчет WASI, кстати, поскольку основная проблема, связанная с несоответствием кодировок строк, будет решена с помощью принуждения.

Наличие отдельного типа string16 как вы предлагаете с суррогатами, по-прежнему будет иметь все проблемы с суррогатами, описанные в interface-types / # 135 , поэтому я думаю, что было бы не лучше иметь два строковых типа vs .one (особенно, если они неявно взаимопреобразуемы; тогда они не являются значимыми отдельными типами). Наличие двух строковых типов также усугубит ситуацию, поскольку создаст психологическую нагрузку для каждого дизайнера интерфейса и потребителя («почему существует два типа? В чем разница? Когда я должен использовать один или другой?»). Наконец, добавление поддержки WTF-16 обычно противоречит будущему руководству по развитию стандартов Web / IETF, также упомянутому в interface-types / # 135 . Таким образом, я не думаю, что нам следует рассматривать добавление суррогатных типов, если у нас нет реальных конкретных доказательств того, что типы интерфейсов без него не жизнеспособны.

Я думаю, что для случаев использования исключительно в Интернете имеет смысл решить проблему с помощью JS или веб-API. Например, легко представить себе JS API для «привязки» импорта и экспорта wasm. Этот подход уже используется в других новых JS API, таких как переключение стека, и мне было интересно, куда мы идем, это общие JS API «импорт привязки» / «экспорт привязки», которые могут обрабатывать Интернет. -конкретные случаи промисов, строк JS и представлений типизированных массивов.

Наличие отдельного типа string16, как вы предлагаете с суррогатами, по-прежнему будет иметь все проблемы с суррогатами, описанные в interface-types / 135

Технически верно, но также упускает из виду, что строки, по крайней мере, всегда будут работать между отдельно скомпилированными модулями на том же языке, на любом совместимом языке и JavaScript, даже без предварительного знания того, с каким модулем происходит взаимодействие. Я думаю, что это, как правило, большинство случаев. Таким образом, мне кажется разумным компромиссом, еще и потому, что он позволяет char желаемый диапазон значений

Наличие двух строковых типов также может серьезно ухудшить ситуацию, создавая психологическую нагрузку на каждого дизайнера интерфейса и потребителя («почему существует два типа? В чем разница? Когда я должен использовать тот или другой?»)

Альтернатива случайной поломке кажется мне намного хуже, поэтому, если это нужно, я думаю, что большинству людей это понравится. Возможно, удачного названия для второго строкового типа ( domstring ?) Будет достаточно, чтобы смягчить эту незначительную проблему.

Наконец, добавление поддержки WTF-16 в целом будет противоречить будущему руководству по развитию стандартов Web / IETF.

К сожалению, из-за отсутствия аварийного выхода для затронутых языков для меня не имеет большого значения, насколько обоснованными являются чьи-либо доводы о предполагаемой тенденции, поскольку до тех пор, пока ИТ-MVP собирается где-то что-то сломать для кого-то и в значительной степени бесполезен я могу только противостоять тому JavaScript-подобному языку, над которым я работаю.

Поэтому я пытаюсь найти разумное решение или компромисс, с которым может жить каждый, и я был бы счастлив, если бы мы могли сотрудничать.

Я не понимаю, как то, что вы говорите, решает проблемы, поднятые в interface-types / # 135, или предоставляет контрдоказательство того, что ИТ в целом не будет жизнеспособным без включения нового типа domstring . Существующий JS API уже предоставляет универсальный аварийный люк для выполнения произвольных преобразований значений на границах, поэтому я не понимаю, зачем нужен второй аварийный люк в такой ранний момент времени. Я думаю, что нам просто нужно больше основанных на опыте доказательств, чтобы противодействовать строгим рекомендациям, которые мы дали против дальнейшего распространения строк, содержащих суррогаты.

(FWIW, если мы можем договориться об отсутствии суррогатов, я думаю, имеет смысл поговорить о поддержке U TF-16 в качестве дополнительной кодировки в каноническом ABI string . Но это отдельная тема с несколько вариантов, поэтому я не хочу смешивать это с семантикой абстрактных строк, которую нужно сначала понять.)

Я ценю ваш второй абзац, так как он уже решил некоторые очень досадные проблемы. Я согласен с тем, что поддержка UTF-16 полезна отдельно, и я был бы признателен за ее добавление в объяснитель / MVP. Считай меня!

Однако мне трудно уследить за вашими аргументами в первом абзаце. Возможно, если вы мне не верите, вот Линус Торвальдс, объясняющий очень важное правило, которое, как мне кажется, выходит за рамки ядра Linux: не нарушайте пространство пользователя . И вот он в том же выступлении, отстаивающий мудрость программиста: если это ошибка, на которую люди полагаются, это не ошибка, это особенность , только для продолжения:

Это действительно печально, когда самая основная библиотека во всей системе может ломать вещи, пока что-то «улучшается» и они «исправляют» ABI.

И отсутствие необходимости беспокоиться о суррогатах - это действительно своего рода функция, поскольку пользователи могут сделать неосторожный substring(0, 1) здесь или там и вызвать с ним импортированную функцию, или могут split("") , передать и join() снова, или создайте StringBuilder как модуль, который иногда не будет давать двойные символы замены, как если бы это было по волшебству. Я имею в виду, что есть причина, по которой группа очень популярных языков отказалась от обеспечения правильной формы, и когда Wasm хочет хорошо поддерживать эти языки и своих пользователей, тогда чем более модульным становится Wasm, тем больше будет границ, труднее станет определить, в каком модуле находится функция, и тем более очевидной станет проблема.

Я действительно не знаю, сколько еще доказательств мне нужно, чтобы доказать, что проектировать что-то таким образом, чтобы игнорировать текущую реальность, - плохая идея. Фактически, это кажется нормальным только для типов интерфейсов, в то время как мы сохраняем все остальные предложения в соответствии с очень высокими стандартами. И хотя я не являюсь экспертом в этом вопросе, я думаю, что стандарт Unicode совершает ту же самую ошибку в отношении потребностей языков UCS-2, настаивая на USV, что привело к примерно десятилетию столь же отчаянных обсуждения (могу порекомендовать весь поток, но особенно последний комментарий перед тем, как он замолчал), кульминацией которого стало описание обычно применяемого практического решения, которое представляет собой кодировку WTF-8.

Обратите внимание, что выдача заменяющего символа при обнаружении ошибок кодирования символов в битовых потоках является хорошо известной формой опасного скрытого искажения данных, и системы, требующие целостности, запрещают это делать.

Соответственно, если codePointAt вызовет исключение при обращении к одинокому суррогату, вы вполне можете получить ошибку, которая нарушит работу всего вашего приложения, потому что кто-то случайно поместил символ эмодзи в неправильную позицию в строке в базе данных.

К сожалению, с помощью ecmascript очень сложно гарантировать, что вы не генерируете строки с непарными суррогатными кодовыми точками где-то в них, это так же просто, как взять первые 157 единиц .length из строки и, возможно, добавить "..." для ее сокращения. И это ужасная случайность, если это действительно происходит на практике, потому что символы, отличные от BMP, встречаются редко. Мы должны очень неохотно вводить опасности, надеясь улучшить нашу гигиену Unicode.

Причина, по которой JS, Java и C # имеют строки, которые они делают, заключается в том, что к тому времени, когда Unicode понял, что 2 байта недостаточно, и, следовательно, UCS-2 был нежизнеспособен, куча кода уже была написана, поэтому эти языки просто не работали. у меня нет выбора. Точно так же для системных вызовов Linux, доступных в пользовательском пространстве. Напротив, сегодня не существует кода, использующего API-интерфейсы, определенные в ИТ, поэтому у нас нет таких же требований к обратной совместимости. По многим причинам wasm и типы интерфейса намеренно не стремятся идеально имитировать существующий единый язык или ABI системных вызовов. Это может быть допустимая цель, но это будет отдельный проект / стандарт / уровень, чем компонентная модель. В этом преимущество разделения и определения объема: нам не нужна одна вещь, которая позволяет достичь всех возможных целей.

Я хочу еще раз подчеркнуть, что, конечно, внутри компонента строки могут быть представлены любым способом, подходящим для языка, поэтому на самом деле мы говорим только о семантике API . Что касается уже определенных веб-API:

1. у нас есть множество причин полагать, что нет необходимости (и часто не имеет смысла) передавать суррогаты
2. всегда есть выход из использования пользовательских привязок JS API (не обязательно, чтобы 100% веб-API имели привязку к веб-API без использования JS-клея)

Таким образом, я все еще не думаю, что у нас есть какие-либо доказательства того, что ИТ не будут жизнеспособными без реализации семантики строк WTF-16, что, на мой взгляд, является подходящим вопросом для MVP.

Пара моментов, с которыми я не согласен:

Я не понимаю, как то, что вы говорите, решает проблемы, поднятые в interface-types / # 135

Теперь это отдельная проблема, и в предыдущем посте я говорил о том, что я считаю разумным компромиссом для решения проблемы потерь. В частности, я был бы согласен с вашими рассуждениями в отдельном выпуске, но только тогда, когда доступен резервный вариант без потерь. На мой взгляд, это не вариант «или / или». Если нет, я бы остался при мнении, что WTF-8/16 является более инклюзивным, менее ограниченным выбором и как таковой предпочтительнее, в том числе потому, что одна из высокоуровневых целей Wasm - беспрепятственная интеграция с веб-платформой, соответственно, поддержание обратного -Совместимость с Интернетом, что также относится к типам интерфейсов.

Существующий JS API уже предоставляет универсальный аварийный люк для выполнения произвольных преобразований значений на границах, поэтому я не понимаю, зачем нужен второй аварийный люк в такой ранний момент времени.

всегда есть выход из использования пользовательских привязок JS API

К сожалению, этого недостаточно в нашем случае, где в настоящее время у нас есть связующий код, например:

const STRING_SMALLSIZE = 192; // break-even point in V8
const STRING_CHUNKSIZE = 1024; // mitigate stack overflow
const utf16 = new TextDecoder("utf-16le", { fatal: true }); // != wtf16

/** Gets a string from memory. */
function getStringImpl(buffer, ptr) {
  let len = new Uint32Array(buffer)[ptr + SIZE_OFFSET >>> 2] >>> 1;
  const wtf16 = new Uint16Array(buffer, ptr, len);
  if (len <= STRING_SMALLSIZE) return String.fromCharCode(...wtf16);
  try {
    return utf16.decode(wtf16);
  } catch {
    let str = "", off = 0;
    while (len - off > STRING_CHUNKSIZE) {
      str += String.fromCharCode(...wtf16.subarray(off, off += STRING_CHUNKSIZE));
    }
    return str + String.fromCharCode(...wtf16.subarray(off));
  }
}

Во-первых, поскольку мы очень заботимся о Chrome и Node.js, мы обнаружили, что TextDecoder V8 для UTF-16LE намного медленнее, чем в других движках (SM действительно быстрые), поэтому String.fromCharCode - это фактически быстрее в V8 до определенной точки безубыточности. Поэтому мы решили пока оптимизировать его. Далее, не существует TextDecoder для WTF-16 (что отдельно раздражает), поэтому мы сначала пытаемся декодировать правильно сформированный UTF-16, а если это не удается, мы позволяем ему бросать и возвращаться к фрагментам гораздо медленнее String.fromCharCode . Разделение на фрагменты необходимо, потому что нельзя просто применить String.fromCharCode к длинной строке, так как это может привести к переполнению стека.

С другой стороны, Rust, например, не нуждался бы в этом, что является одной из причин, почему я думаю, что ИТ сейчас не так нейтрально, как должно быть. В общем, я думаю, что смысл IT string s действительно в том, чтобы иметь возможность хорошо взаимодействовать с JS, который по-прежнему является нашей основной целью взаимодействия.

Сегодня не существует кода, который использует API, определенные в ИТ, поэтому у нас нет таких же требований к обратной совместимости

Первая половина технически верна, поскольку ИТ еще не существует, но наши требования IIUC включают улучшение существующих вариантов использования, например, учет неуклюжего фрагмента связующего кода выше. В идеале для максимально возможного количества языков, чтобы пост-MVP действительно стал «просто оптимизацией», как вы сказали в своей презентации. Напротив, прямо сейчас ИТ в основном начинают с того, что уже является оптимизацией для языков, которые могут использовать кодировщик / декодер UTF-8, что, на мой взгляд, не является нейтральным.

wasm и типы интерфейса намеренно не стремятся идеально имитировать существующий единый язык или системный вызов ABI.

Я читаю это так, как будто я придерживаюсь этого мнения, чего я совершенно не придерживаюсь. Я готов предоставить вам преимущество сомнения здесь, но хотел бы добавить, что, на мой взгляд, ИТ в настоящее время излишне ограничены и поэтому хорошо обслуживают только очень специфический набор языков. Напротив, WTF-8/16 - это более инклюзивная кодировка, которая, как я ожидал, будет логическим значением по умолчанию, в том числе потому, что она обращается к строкам JS. Мы не согласны с этим, но только из-за отсутствия надлежащего аварийного люка. Если бы существовала жизнеспособная альтернатива без потерь, чтобы никто не сломался или не оказался в невыгодном положении, я был бы в порядке с вашими рассуждениями о строковом типе по умолчанию.

у нас есть множество причин полагать, что нет необходимости (и часто не имеет смысла) передавать суррогаты

Мы здесь не согласны. В частности, я думаю, что моя презентация и комментарии вызывают обоснованные сомнения в том, что в некоторых случаях, хотя и редко, но они могут быть очень значимыми (например, там, где требуется целостность), и я считаю, что «Мы должны очень неохотно вводить опасности в надежде улучшить нашу гигиену Unicode ". То есть, если мы можем, я считаю, что мы должны разработать канонический ABI таким образом, чтобы он гарантированно работал и в следующих важных случаях: Java / C # / AS <-> JS, Java / C # / AS <-> Java / C # / AS. Замена на другие пути, вероятно, неизбежна, но, по крайней мере, у языков и пользователей есть выбор, соответственно, в редких случаях значение по умолчанию еще не нарушено.

Я все еще не думаю, что у нас есть какие-либо доказательства того, что ИТ не будет жизнеспособным, если не будет продвигать эту строковую семантику WTF-16.

При наличии разумных сомнений и отсутствия желания исследовать то, что я считаю разумным компромиссом, я ожидаю, что бремя доказывания теперь лежит на вас. Опять же, я готов оставить строку по умолчанию на ваше усмотрение и хорошо сформированное будущее, но не за счет того, чтобы не учитывать то, что может быть редким, но все же опасностями. Это может повлиять на многие популярные языки, и это может стать действительно трудно оправдать в будущем, когда они осознают.

Я согласен с тем, что связующий код JS не идеален, но я думаю, что правильное решение для этого находится в JS API или в JS, а не путем добавления концепции wtf-16-string ко всей будущей экосистеме компонентов. Помимо этого, я не вижу новой информации, на которую еще не ответили; похоже, что мы в основном расходимся во мнениях по вопросам целей / масштабов.

Я ожидал, что аномалию TextDecoder будет еще сложнее исправить в JS, поскольку он, по-видимому, уже решил, что это выходит за рамки. И JS вроде как может это делать, потому что TextDecoder в JS не вызывается между двумя вызовами функций , а в основном используется для извлечения данных по сети или из хранилища.

Еще более интересная аномалия, это, однако, что даже не TextEncoder для UTF-16LE, так что нужно сделать:

/** Allocates a new string in the module's memory and returns its pointer. */
function __newString(str) {
  if (str == null) return 0;
  const length = str.length;
  const ptr = __new(length << 1, STRING_ID);
  const U16 = new Uint16Array(memory.buffer);
  for (var i = 0, p = ptr >>> 1; i < length; ++i) U16[p + i] = str.charCodeAt(i);
  return ptr;
}

Как видите, это основная проблема для чего-то вроде Java, C #, AS и других, и оба они по-прежнему необходимы, если передается list u16 . И в контексте этой проблемы он не является эксклюзивным для JS API, в этом двойном перекодировании + потери между двумя модулями одного и того же языка не так уж и отличаются :(

Помимо TextEncoder / TextDecoder , существует целый ряд вариантов решения этого варианта использования в Интернете. Другой - расширение new WebAssembly.Function() (которое уже реализовано в некоторых браузерах) для выполнения преобразования строк путем добавления дополнительных необязательных параметров в конструктор. Такой подход также сделает функциональные возможности доступными для некомпонентного использования wasm (и, возможно, намного раньше), подтверждая мысль о том, что JS API будет правильным местом для решения этого варианта использования.

К вашему сведению: в список предложений выше добавлен параметр «Integrated W / UTF-any», который появился в https://github.com/WebAssembly/interface-types/issues/135#issuecomment -863493832 :)