Design: Discussão: WebAssembly, Unicode e a plataforma da Web

Talvez algumas soluções em potencial que coletei no feedback off-line até agora, para consideração:

WTF-16 separado

Em Tipos de Interface, defina:

string   := list char
string16 := list u16

Defina uma coerção aplicada durante a vinculação, com os seguintes casos:

| De | Para | Expectativa
| ------------ | ------------ | -------------
| string | string16 | Recodificar de UTF-8 para UTF-16
| string16 | string | Recodificar de WTF-16 para UTF-8 (opção de substituição)

A coerção garante que um módulo string16 funcione em um host WASI, respectivamente que um módulo string e string16 possam interagir um com o outro, mesmo se ambos forem string e um string16 módulo ou host chamam o mesmo string ou string16 export, que de outra forma seria ambíguo.

Este também introduz uma ambigüidade na incorporação da Web em que passar list u16 para JS poderia se tornar Uint16Array ou DOMString . Uma coerção ampla de JS de Uint16Array a DOMString parece indesejável, mas o tipo JS pode ser sugerido usando explicitamente o alias string16 (com seu próprio id binário, string16 :> list u16 sendo puramente semântico onde necessário) em vez de list u16 em um módulo adaptador. Daí o apelido. Nesse caso, string16 se tornaria DOMString enquanto list u16 se tornaria Uint16Array .

Não estou particularmente apegado ao nome string16 e ficaria bem com qualquer outro nome, ou qualquer alternativa que não requeira um nome / id para resolver a ambigüidade.

Uma otimização semelhante a list.is_canon não é necessária aqui, uma vez que list.count pode ser usado. Além disso, a porta para UTF-any e uma potencial otimização Latin1, conforme abaixo, pode ser mantida aberta reservando-se espaço para um futuro imediato nas instruções do adaptador list.*_canon .

UTF-any

Em Tipos de Interface, defina:

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)

Esta solução potencial pode ser considerada onde a boa formação é necessária. Isso evitaria a sobrecarga de recodificação dupla e efeitos indiretos no tamanho do código, mas deixaria o problema substituto sem solução. Observe que $unit 1-3 podem ser adicionados pós-MVP como otimizações adicionais, ou podemos começar com algumas delas imediatamente.

WTF-any

Em Tipos de Interface, defina:

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)

Essa solução potencial também exigiria a redefinição de char de valores escalares Unicode para pontos de código Unicode, enquanto restringia as listas de char para não conter pares substitutos (mas permitindo substitutos isolados), potencialmente aplicados durante o levantamento. Novamente, $unit s concretos em um MVP são discutíveis.

Este não introduz perdas por si só, então todo o resto se torna apenas uma otimização pós-MVP.

W / UTF-any integrado

Em tipos de interface, defina:

• Levante a "lista de pontos de código Unicode que corrige pares substitutos", mas diminua a "lista de valores escalares Unicode". Esta é uma alteração não funcional apenas de design quando aplicada apenas durante o levantamento de 16 bits.
• Adicione uma opção opcional passthrough ao diminuir para obter uma "lista de pontos de código Unicode". Esta é uma adição funcional que permite a passagem sem perdas.

Ao fazer isso, alcançamos:

• Boa formação por padrão
• Codificação sem perdas para idiomas WTF como uma opção
• Quando combinado com https://github.com/WebAssembly/interface-types/issues/136#issuecomment -861799460: Codificadores integrados para a maioria (todos?) Dos idiomas que desejamos oferecer bom suporte

IIUC, o problema principal é que a TI deseja que as strings sejam sequências de pontos de código Unicode, mas algumas linguagens consideram as strings como sequências de valores i8 ou i16 que podem ou não corresponder a strings Unicode bem formadas. Uma solução simples seria fazer com que as linguagens / APIs que aceitem ou produzam strings Unicode inválidas usem (list u8) ou (list u16) (possivelmente com algum apelido legal como byte_string para comunicar a intenção) em vez de o tipo IT string , que IIRC é um apelido para (list char) . As compensações de fazer isso já foram discutidas em algum lugar?

Acho que o problema tem um pouco mais de nuances, pois a TI deseja definir char como "Valores escalares Unicode", que têm uma lacuna onde estariam os pontos do código substituto e, como tal, não podem representar substitutos isolados . WTF, por outro lado, é "Unicode Code Points" sem esta restrição, mas sequências sendo restritas para não conter pares de pontos de código substitutos (estes seriam substituídos por pontos de código suplementares> U + FFFF, enquanto substitutos isolados estão OK). É isso que você queria dizer?

Fora isso, acho que strings de bytes semelhantes a C a partir de const char* que podem ser qualquer coisa, ainda não foram discutidas. Eu posso ter perdido isso, no entanto.

Uma solução simples seria fazer com que as linguagens / APIs que aceitem ou produzam strings Unicode inválidas usem (list u8) ou (list u16) (possivelmente com algum apelido legal como byte_string para comunicar a intenção) em vez de o tipo IT string , que IIRC é um apelido para (list char) .

Esta também é minha solução preferida - um tipo wtf16string seria um apelido para (list u16) da mesma forma que string é atualmente definido como um apelido para (list char) . O valor do alias, IIUC, é que o resultado de uma função retornando (list u16) chamada por (por exemplo) JS apareceria como uma lista JS (de números), enquanto o resultado de uma função retornando wtf16string pode ser especificado como aparecendo em JS como uma string JS.

Adicionar um alias wtf16string ao ABI canônico de rascunho parece ser relativamente pouco intrusivo.

WTF, por outro lado, é "Unicode Code Points" sem esta restrição, mas sequências sendo restritas para não conter pares de pontos de código substitutos (estes seriam substituídos por pontos de código suplementares> U + FFFF, enquanto substitutos isolados estão OK).

Ah, isso significa que WTF-8 não é o mesmo que (list u16) simples porque tem essa restrição de adição? Eu não tinha apreciado essa nuance. Minha intuição é que seria um exagero ter um tipo string representando sequências de valores escalares Unicode bem formados, bem como um tipo wtf16string que é quase (list u16) mas tem restrições adicionais. Usar um apelido para (list u16) irrestrito funcionaria bem o suficiente para sistemas que não impõem a boa formação unicode? Esta nota nas especificações WTF-8 sugere que sim.

Ah, isso significa que WTF-8 não é o mesmo que simples (lista u16) porque tem essa restrição de adição?

Ele afirma que "Como o UTF-8 é artificialmente restrito ao texto Unicode para corresponder ao UTF-16, o WTF-8 é artificialmente restrito para excluir pares de pontos de código substituto para corresponder ao UTF-16 potencialmente malformado." Ou seja, ele os trata de forma semelhante a como o UTF-8 trata as sequências de bytes truncadas ou excessivamente longas. WTF-8 pode representar qualquer (list u16) , mas nem todo (list u8) é um WTF-8 válido.

Usar um alias para um irrestrito (lista u16) funcionaria bem o suficiente para sistemas que não impõem a boa formação unicode?

WTF-16 mapeia 1: 1 para valores u16 aleatórios e depende apenas de como esses valores são interpretados, então sim, (list u16) funcionaria.

IIUC, WTF-8 não é exatamente o mesmo que list u8 arbitrário. Por exemplo, ele proíbe "sequências de bytes de pares substitutos" (veja aqui ).

No entanto, WTF-16 _é_ o mesmo que list u16 . É um pouco estranho que eles compartilhem um tema de nomenclatura.

EDITAR: deveria ter atualizado :)

Eu postei uma primeira pergunta / resposta focada apenas na questão dos substitutos em interface-types / # 135 . Acho que essa é a parte de alta ordem e, se pudermos concordar com isso, uma discussão subsequente sobre o suporte de um ou mais formatos de codificação será mais simples.

Obrigada, Luke.

Se você estiver disposto a oferecer suporte a "Separar WTF-16" conforme descrito acima (a coerção é crucial para habilitar o acesso às APIs WASI e para fazer a interface com JavaScript sem código de cola), eu me sentiria confortável com o char sugerido faixa de valor. As linguagens WTF-16 teriam então a saída de emergência de que precisam para se integrar tão bem quanto os módulos escritos na mesma linguagem, JavaScript e por meio da substituição por linguagens UTF- *. Eu também me sentiria muito melhor com o WASI aliás, já que o principal problema introduzido pela incompatibilidade das codificações das cordas seria resolvido com a coerção no lugar.

Ter um tipo string16 separado como você está sugerindo com substitutos ainda teria todos os problemas com substitutos descritos em interface-types / # 135 , então eu acho que não seria melhor ter dois tipos de string vs um (especialmente se eles forem implicitamente interconvertíveis; então não são tipos significativamente separados). Ter dois tipos de string também tornaria as coisas concretamente piores, introduzindo uma carga mental em cada designer de interface e consumidor ("por que existem dois tipos? Qual é a diferença? Quando devo usar um ou o outro?"). Por último, adicionar suporte para WTF-16 geralmente iria contra a orientação de evolução de padrões futuros da Web / IETF também mencionada em interface-types / # 135 . Portanto, não acho que devemos considerar a adição de tipos de rolamento substitutos, a menos que tenhamos evidências concretas de que os Tipos de Interface não são viáveis ​​sem eles.

Para casos de uso exclusivo da Web, acho que faria sentido resolver o problema no JS ou nas APIs da Web. Por exemplo, é fácil imaginar APIs JS para "vincular" importações e exportações de wasm. Esta já é uma abordagem que está sendo adotada em outras APIs JS emergentes, como a troca de pilha, e estou me perguntando se para onde estamos indo é "importação de ligação" / "exportação de ligação" APIs JS que são capazes de lidar com a Web -casos específicos de Promises, strings JS e visualizações de array digitadas.

Ter um tipo de string16 separado, como você está sugerindo com substitutos, ainda teria todos os problemas com substitutos descritos em interface-types / 135

Tecnicamente verdadeiro, mas também esquece que as strings sempre funcionariam entre módulos compilados separadamente na mesma linguagem, qualquer linguagem compatível e JavaScript, mesmo sem conhecimento prévio de que tipo de módulo se está fazendo interface. Essa é a maioria dos casos, eu acho. Como tal, parece-me um meio-termo razoável, também porque permite dedicar a gama de valores char desejada a cadeias de caracteres bem formadas (USV).

Ter dois tipos de string também tornaria as coisas concretamente piores, ao introduzir uma carga mental em cada designer de interface e consumidor ("por que existem dois tipos? Qual é a diferença? Quando devo usar um ou o outro?")

A alternativa de quebras ocasionais parece muito pior para mim, então, se for necessário, acho que a maioria das pessoas aceitará isso. Talvez um bom nome para o segundo tipo de string ( domstring ?) Seja suficiente para mitigar este pequeno problema.

Por último, adicionar suporte para WTF-16 geralmente iria contra as futuras orientações de evolução de padrões Web / IETF

Infelizmente, na ausência de uma saída de emergência para os idiomas afetados, não importa muito para mim o quão sólido é o raciocínio de alguém sobre uma suposta tendência, uma vez que, enquanto o MVP de TI vai quebrar algo em algum lugar para alguém, e é amplamente inútil para a linguagem semelhante ao JavaScript em que estou trabalhando, só posso me opor a ela.

Portanto, estou tentando encontrar uma solução ou compromisso razoável com o qual todos possam viver, e ficaria feliz se pudéssemos cooperar.

Não vejo como o que você está dizendo aborda os problemas levantados em interface-types / # 135 ou fornece contra-evidências de que a TI não seria viável em geral sem a inclusão de um novo tipo domstring . A API JS existente já fornece uma saída de emergência de propósito geral para fazer conversões de valores arbitrários em limites, portanto, não vejo como uma segunda saída de emergência é necessária neste momento inicial. Acho que simplesmente precisamos de mais evidências baseadas na experiência para neutralizar a forte orientação que recebemos contra a propagação de strings contendo substitutos.

(FWIW, se pudermos concordar com a ausência de substitutos, acho que faria sentido falar sobre o suporte do U TF-16 como uma codificação adicional na ABI canônica de string . Mas esse é um tópico totalmente separado com algumas opções, então eu não quero misturar isso com a semântica de string abstrata que precisa ser entendida primeiro.)

Agradeço seu segundo parágrafo, pois já resolveria alguns problemas muito chatos. Concordo que o suporte a UTF-16 é útil separadamente e gostaria que ele fosse adicionado ao explicador / MVP. Conte comigo!

Estou tendo dificuldade em seguir seus argumentos no primeiro parágrafo, no entanto. Talvez, se você não acredita em mim, aqui está Linus Torvalds explicando uma regra muito importante que eu acho que vai além do kernel do Linux: Não interrompa o espaço do usuário . E aqui está ele na mesma palestra, defendendo a sabedoria do programador de Se é um bug no qual as pessoas confiam, não é um bug, é um recurso , apenas para continuar com:

É realmente triste quando a biblioteca mais central em todo o sistema está OK em quebrar coisas, desde que as coisas "melhorem" e "consertem" a ABI.

E não ter que se preocupar com substitutos é de fato uma espécie de recurso, em que os usuários podem fazer um substring(0, 1) descuidado aqui ou ali e chamar uma função importada com ele, ou podem split("") , passar adiante e join() novamente, ou crie um StringBuilder como um módulo que não produzirá ocasionalmente caracteres de substituição dupla como se fosse mágico. Quero dizer, há uma razão pela qual um monte de linguagens muito populares optou por não impor a boa formação, e quando o Wasm deseja oferecer suporte a essas linguagens e aos seus usuários, quanto mais modular o Wasm se torna, mais limites haverá, o será mais difícil dizer em qual módulo uma função reside e mais evidente o problema se tornará.

Eu realmente não sei quantas evidências mais preciso para provar que projetar algo de uma forma que ignore a realidade atual é uma má ideia. Na verdade, isso parece ser OK apenas em tipos de interface, enquanto mantemos todas as outras propostas com padrões muito elevados. E embora eu não seja um especialista nisso, acho que foi o próprio padrão Unicode cometendo exatamente o mesmo erro em relação às necessidades das linguagens UCS-2 ao insistir em USVs, levando a cerca de uma década de desespero semelhante discussões (pode recomendar o tópico inteiro, mas especialmente o último comentário antes de silenciar), em 2014 culminando na descrição da solução prática comumente aplicada que é a codificação WTF-8.

Observe que a emissão de um caractere de substituição ao encontrar erros de codificação de caracteres em fluxos de bits é uma forma bem conhecida de corrupção silenciosa e perigosa de dados e sistemas que exigem integridade proíbem isso.

Da mesma forma, se codePointAt lançaria uma exceção ao atingir um substituto solitário, você pode muito bem acabar com um bug que quebra todo o seu aplicativo porque alguém acidentalmente colocou um caractere emoji na posição errada em uma string em um banco de dados

Infelizmente, o ecmascript torna muito difícil garantir que você não gere strings com pontos de código substituto não pareados em algum lugar deles, é tão fácil quanto pegar as primeiras 157 unidades de comprimento de uma string e talvez acrescentar "..." para abreviá-la. E é um acidente estranho se isso realmente acontecer na prática, porque personagens não-BMP são raros. Devemos ser muito relutantes em introduzir riscos na esperança de melhorar nossa higiene Unicode.

O motivo pelo qual JS, Java e C # têm as strings que possuem é que, quando o Unicode percebeu que 2 bytes não eram suficientes e, portanto, o UCS-2 não era viável, um monte de código já estava escrito, então essas linguagens simplesmente não não tenho escolha. Da mesma forma, para syscalls do Linux expostos ao espaço do usuário. Em contraste, não existe nenhum código hoje que use APIs definidas em TI, então não temos os mesmos requisitos de compatibilidade com versões anteriores. Por muitas razões, o wasm e os tipos de interface não buscam intencionalmente emular perfeitamente uma única linguagem existente ou ABI syscall. Pode ser um objetivo válido, mas seria um projeto / padrão / camada separado do modelo de componente. Este é o benefício da disposição em camadas e do escopo: não precisamos de algo que atinja todos os objetivos possíveis.

Quero enfatizar novamente que, é claro, dentro de um componente, as strings podem ser representadas de qualquer maneira que seja apropriada para a linguagem, então, na verdade, estamos falando apenas sobre a semântica das APIs . Quanto às APIs da Web já definidas:

1. temos muitos motivos para acreditar que não é necessário (e muitas vezes não é significativo) passar substitutos
2. sempre há uma saída de emergência de usar associações de API JS personalizadas (não é um requisito que 100% das APIs da Web tenham uma associação JS-glue-less para APIs da Web)

Portanto, ainda não acho que temos qualquer evidência sugerindo que a TI não será viável sem levar adiante essas semânticas de string WTF-16, que acho que é a pergunta apropriada para um MVP.

Alguns pontos dos quais discordo:

Não vejo como o que você está dizendo resolve os problemas levantados nos tipos de interface / # 135

Este é um problema separado agora, e no post anterior eu estava falando sobre o que acredito ser um meio-termo razoável para resolver perdas. Em particular, concordaria com seu raciocínio na edição separada, mas apenas quando houver um fallback sem perdas disponível. Este não é um ou / ou na minha opinião. Caso contrário, continuaria a ser da opinião que WTF-8/16 é a escolha mais inclusiva e menos restrita e, como tal, é preferível, também porque um dos objetivos de alto nível do Wasm é integrar-se perfeitamente com a plataforma da Web, respectivamente, manter o retrocesso - natureza compatível da Web, e isso também se aplica aos Tipos de Interface.

A API JS existente já fornece uma saída de emergência de propósito geral para fazer conversões de valores arbitrários em limites, portanto, não vejo como uma segunda saída de emergência é necessária neste momento inicial.

sempre há uma saída de emergência de usar associações de API JS personalizadas

Infelizmente, isso não é suficiente em nosso caso, onde atualmente temos um código de cola como:

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));
  }
}

Em primeiro lugar, como nos preocupamos muito com o Chrome e Node.js, descobrimos que TextDecoder do V8 para UTF-16LE é muito mais lento do que em outros motores (SM é muito rápido), então String.fromCharCode é realmente mais rápido no V8 até um certo ponto de equilíbrio. Portanto, decidimos otimizar em torno disso por enquanto. Em seguida, não existe TextDecoder para WTF-16 (o que é irritante separadamente), então primeiro tentamos decodificar o UTF-16 bem formado e, se isso falhar, deixamos que ele seja jogado e retornado ao processo de fragmentação o muito mais lento String.fromCharCode . O chunking é necessário porque não se pode simplesmente aplicar String.fromCharCode em uma string longa, pois isso pode estourar a pilha.

Por outro lado, Rust, por exemplo, não precisaria disso, o que é uma das razões pelas quais eu acho que a TI, agora, não é tão neutra quanto deveria ser. Em geral, acho que o objetivo de IT string s é, de fato, ser capaz de interagir bem com JS, que ainda é nosso principal objetivo de interoperabilidade.

nenhum código existe hoje que usa APIs definidas em TI, então não temos os mesmos requisitos de compatibilidade com versões anteriores

A primeira metade é tecnicamente verdadeira, uma vez que a TI ainda não existe, mas nossos requisitos do IIUC incluem a melhoria dos casos de uso existentes, como, por exemplo, a contabilização do pedaço desajeitado do código de cola acima. Idealmente, para o máximo de idiomas possível, então o pós-MVP torna-se de fato "apenas uma otimização", como você disse em sua apresentação. Pelo contrário, agora a TI começa basicamente com o que já é uma otimização para linguagens que podem fazer uso de um codificador / decodificador UTF-8, que eu acho que não é neutro.

wasm e Interface Types intencionalmente não procuram emular perfeitamente uma única linguagem existente ou ABI syscall

Eu li isso como se tivesse essa opinião, o que não sou de todo. Estou disposto a lhe dar o benefício da dúvida aqui, mas gostaria de acrescentar que, em minha opinião, a TI é atualmente desnecessariamente restrita e, como tal, atende bem apenas um conjunto muito específico de idiomas. Ao contrário, WTF-8/16 é a codificação mais inclusiva que eu esperava ser o padrão lógico, também porque faz viagens de ida e volta para strings JS. Discordamos aqui, mas apenas na ausência de uma saída de emergência adequada. Se existisse uma alternativa viável sem perdas, de forma que ninguém ficasse quebrado ou desnecessariamente prejudicado, eu estaria bem com seu raciocínio sobre o tipo de string padrão.

temos muitos motivos para acreditar que não é necessário (e muitas vezes não é significativo) passar substitutos

Nós discordamos aqui. Em particular, acho que minha apresentação e comentários apresentam dúvidas razoáveis ​​de que pode, em alguns casos, mesmo que raros, ser muito significativo (digamos onde a integridade é exigida), e eu sou da opinião que "Devemos ser muito relutantes em apresentar riscos na esperança de melhorar nossa higiene Unicode. " Ou seja, se pudermos, acredito que devemos projetar a ABI canônica de forma que funcione também nos seguintes casos importantes: Java / C # / AS <-> JS, Java / C # / AS <-> Java / C # / AS. A substituição em outros caminhos é provavelmente inevitável, mas pelo menos os idiomas e os usuários têm uma escolha, respectivamente, o padrão ainda não foi quebrado em casos raros.

Eu ainda não acho que temos qualquer evidência sugerindo que a TI não será viável sem levar adiante essas semânticas de string WTF-16

Na presença de dúvida razoável e na ausência de vontade de explorar o que acredito ser um compromisso razoável, esperaria que o ônus da prova agora recaia sobre você. Mais uma vez, estou disposto a deixar a corda padrão para você e um futuro bem formado, mas não às custas de não levar em conta o que pode ser raro, mas ainda assim, riscos. Muitas linguagens populares podem ser afetadas por isso, e isso pode se tornar muito difícil de justificar no futuro, uma vez que percebam.

Concordo que o código de cola JS não é ideal, mas acho que a correção certa para isso está na API JS ou em JS, não adicionando o conceito de wtf-16-string a todo o futuro ecossistema de componentes. Além disso, não vejo novas informações para responder que ainda não tenham sido respondidas; parece que discordamos principalmente em questões de objetivos / escopo.

Eu esperaria que a anomalia TextDecoder fosse ainda mais difícil de consertar em JS, uma vez que aparentemente já decidiu que isso está fora do escopo. E JS pode meio que fazer isso, porque TextDecoder em JS não é algo que é invocado entre duas chamadas de função , mas principalmente usado para recuperar dados pela rede ou do armazenamento.

A anomalia ainda mais interessante é, no entanto, que não há nem mesmo TextEncoder para UTF-16LE, então é preciso fazer:

/** 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;
}

Como você pode ver, este é um grande problema para algo como Java, C #, AS e outros, e ambos ainda seriam necessários quando um list u16 é passado. E no contexto deste problema não é exclusivo para a API JS, pois a dupla recodificação + perda de perdas entre dois módulos da mesma linguagem não é tão diferente :(

Há todo um espaço de opções além de TextEncoder / TextDecoder para saber como lidar com esse caso de uso na web. Outra é estender new WebAssembly.Function() (que já está implementado em alguns navegadores) para realizar conversões de string adicionando parâmetros opcionais adicionais ao construtor. Essa abordagem também disponibilizaria a funcionalidade para usos não componentes do wasm (e potencialmente muito mais cedo), reforçando o ponto de que a API JS seria o lugar certo para abordar esse caso de uso.

Para sua informação: Adicionada a opção "Integrated W / UTF-any" que surgiu em https://github.com/WebAssembly/interface-types/issues/135#issuecomment -863493832 à lista de sugestões acima :)