Design: ディスカッション：WebAssembly、Unicode、およびWebプラットフォーム

おそらく、検討のために、これまでオフラインフィードバックから収集したいくつかの潜在的な解決策です。

別の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なる可能性があるという、Web埋め込みのあいまいさをもたらします。 Uint16ArrayからDOMString Uint16ArrayへのJS全体の強制は望ましくないようですが、エイリアスstring16 （独自のバイナリID、 string16 :> list u16明示的に使用することでJSタイプを示唆できます。 list u16アダプタモジュールインチしたがって、エイリアス。 この場合、 string16はDOMString 、 list u16はUint16Arrayます。

私はstring16という名前に特に執着しているわけではなく、他の名前や、あいまいさを解決するために名前/ IDを必要としない別の名前でも問題ありません。

list.countを使用できるため、ここではlist.is_canonような最適化は必要ありません。 また、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リストにサロゲートペアが含まれないように制限します（ただし、分離されたサロゲートを許可します）。 繰り返しますが、MVPの具体的な$unitは議論の余地があります。

これはそれ自体で損失をもたらすものではないため、他のすべては実際にMVP後の最適化になります。

統合されたW / UTF-任意

インターフェースタイプで、以下を定義します。

• 「サロゲートペアを修正するUnicodeコードポイントのリスト」を持ち上げますが、「Unicodeスカラー値のリスト」を下げます。 これは機能しない設計です。16ビットのリフティング中にのみ適用された場合にのみ変更されます。
• 「Unicodeコードポイントのリスト」を取得するために下げるときに、オプションのpassthroughオプションを追加します。 これは、ロスレスパススルーを可能にする機能追加です。

そうすることで、次のことが達成されます。

• デフォルトで整形式
• オプションとしてのWTF言語のロスレスエンコーディング
• https://github.com/WebAssembly/interface-types/issues/136#issuecomment -861799460と組み合わせると、サポートしたいほとんどの（すべての？）言語用の組み込みエンコーダー

IIUC、根本的な問題は、ITが文字列をUnicodeコードポイントのシーケンスにすることを望んでいることですが、一部の言語では、文字列を整形式のUnicode文字列に対応する場合と対応しない場合があるi8またはi16値のシーケンスと見なします。 簡単な解決策の1つは、無効なUnicode文字列を受け入れるまたは生成する言語/ APIで、意図を伝達するのではなく、 (list u8)または(list u16) （おそらくbyte_stringなどの優れたエイリアスを使用）を使用することです。 IT stringタイプ。IIRCは(list char)エイリアスです。 それを行うことのトレードオフについては、まだどこかで議論されていますか？

この問題はもう少し微妙な違いがあると思います。IT部門はcharを「Unicodeスカラー値」として定義したいのですが、サロゲートコードポイントがある場所に穴が開いているため、孤立したサロゲートを表すことはできません。 。 一方、WTFはこの制限のない「ユニコードコードポイント」ですが、シーケンスにはサロゲートコードポイントのペアが含まれないように制限されています（これらは補足コードポイント> U + FFFFに置き換えられますが、分離されたサロゲートは問題ありません）。 これはあなたが意味したことですか？

それ以外は、 const char*時点でCのようなバイト文字列はまだ議論されていないと思います。 しかし、私はそれを見逃したかもしれません。

簡単な解決策の1つは、無効なUnicode文字列を受け入れるまたは生成する言語/ APIで、意図を伝達するのではなく、 (list u8)または(list u16) （おそらくbyte_stringなどの優れたエイリアスを使用）を使用することです。 IT stringタイプ。IIRCは(list char)エイリアスです。

これは現在私の好みの解決策でもあります- stringが現在(list char)エイリアスとして定義されているのと同じように、 wtf16stringタイプは(list u16)のエイリアスになります(list char) 。 エイリアスIIUCの値は、（たとえば）JSによって呼び出された(list u16)返す関数の結果が（数値の）JSリストとして表示されるのに対し、 wtf16string返す関数の結果です。

ドラフトの正規ABIにwtf16stringエイリアスを追加することは、比較的邪魔にならないようです。

一方、WTFはこの制限のない「ユニコードコードポイント」ですが、シーケンスにはサロゲートコードポイントのペアが含まれないように制限されています（これらは補足コードポイント> U + FFFFに置き換えられますが、分離されたサロゲートは問題ありません）。

ああ、それは、この追加制限があるため、WTF-8がプレーンな(list u16)と同じではないことを意味しますか？ 私はそのニュアンスを理解していませんでした。 私の直感では、それは両方持ってやり過ぎだろうということですstring整形ユニコードスカラ値の配列ならびに表現型wtf16stringほとんどであるタイプ(list u16)が、追加の制限があります。 無制限の(list u16)エイリアスを使用すると、Unicodeの整形式性を強制しないシステムで十分に機能しますか？ WTF-8仕様のこの注記は、そうなることを示唆しています。

ああ、それは、この追加制限があるため、WTF-8がプレーン（リストu16）と同じではないことを意味しますか？

「UTF-8がUTF-16と一致するようにUnicodeテキストに人為的に制限されているように、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はlist u16と同じです。 彼らがネーミングテーマを共有しているのは少し奇妙です。

編集：更新する必要があります:)

interface-types /＃135のサロゲートの質問だけに焦点を当てた最初の質問/回答を投稿しました。 これが上位ビットだと思います。それに同意できれば、1つ以上のエンコード形式のサポートに関するその後の説明が簡単になります。

ありがとう、ルーク。

上記の「SeparateWTF-16」をサポートする場合（WASI APIへのアクセスを有効にし、グルーコードなしでJavaScriptとインターフェイスするためには強制が重要です）、提案されたchar満足し

サロゲートで提案しているように別のstring16タイプを使用すると、 interface-types /＃135で概説されているサロゲートに関するすべての問題が発生するため、2つの文字列タイプを使用する方が良いとは思いません。 .1つ（特にそれらが暗黙的に相互変換可能である場合;それらは意味のある別々の型ではありません）。 2つの文字列タイプがあると、すべてのインターフェイス設計者と消費者に精神的な負担がかかるため、事態はさらに悪化します（「なぜ、2つのタイプがあるのか​​、違いは何ですか？どちらをいつ使用する必要があるのですか？」）。 最後に、WTF-16のサポートを追加すると、一般に、 interface-types /＃135でも言及されている将来の標準進化ガイダンスWeb / IETFに反し

Web専用のユースケースの場合、JSまたはWebAPIの問題を解決することは理にかなっていると思います。 たとえば、wasmのインポートとエクスポートを「バインド」するためのJSAPIを想像するのは簡単です。 これは、スタックスイッチングなどの他の新しいJS APIですでに採用されているアプローチであり、Webを処理できる一般的な「バインドインポート」/「バインドエクスポート」JSAPIがどこに行くのか疑問に思っていました。 -Promises、JS文字列、および型付き配列ビューの特定のケース。

サロゲートで提案しているような別のstring16タイプがあると、interface-types / 135で概説されているサロゲートに関するすべての問題が発生します。

技術的には正しいですが、文字列は、インターフェースしているモジュールの種類についての事前の知識がなくても、少なくとも常に同じ言語、互換性のある言語、およびJavaScriptで別々にコンパイルされたモジュール間で機能することを見逃しています。 これは通常、私が思うケースの大部分です。 そのため、私には妥当な妥協案のように思えます。また、必要なchar値の範囲を整形式（USV）の文字列専用にすることができるためです。

2つの文字列タイプがあると、すべてのインターフェイスデザイナーとコンシューマーに精神的な負担がかかるため、事態はさらに悪化します（「2つのタイプがあるのはなぜですか？違いは何ですか？どちらをいつ使用する必要がありますか？」）

時折の破損の代替案は私にははるかに悪いように思われるので、それが必要な場合は、ほとんどの人がそれで大丈夫だと思います。 おそらく、この小さな問題を軽減するには、2番目の文字列型（ domstring ？）の適切な名前で十分です。

最後に、WTF-16のサポートを追加すると、通常、将来の標準進化ガイダンスWeb / IETFに反します。

残念ながら、影響を受ける言語のエスケープハッチがない場合、IT MVPが誰かのためにどこかで何かを壊し、ほとんど役に立たない限り、誰かが主張する傾向をどのように推論するかは私にはあまり重要ではありません私が取り組んでいるJavaScriptのような言語の場合、私はそれに反対することしかできません。

ですから、私は誰もが一緒に暮らせる合理的な解決策や妥協点を見つけようとしています。私たちが協力できれば幸いです。

あなたの言っていることが、 interface-types /＃135で発生した問題にどのように対処しているか、または新しいdomstringタイプを含めないとITが一般的に実行可能強力なガイダンスに対抗するには、より多くの経験に基づく証拠が必要だと思います。

（私たちはサロゲートの不在に同意できる場合FWIWは、私はそれがの正規のABIで追加のエンコーディングとしてU TF-16を支持について話をする意味になるだろうと思いますstring 。しかし、それはと全体の別のトピックですいくつかのオプションがあるので、最初に理解する必要のある抽象的な文字列のセマンティクスと混同したくありません。）

私はあなたの2番目の段落に感謝します、それはすでにいくつかの非常に厄介な問題を解決するでしょう。 UTF-16のサポートが個別に役立つことに同意し、説明者/ MVPに追加していただければ幸いです。 私を数えてください！

しかし、私は最初の段落であなたの議論に従うのに苦労しています。 おそらくあなたが私を信じていないのなら、ここにLinus Torvaldsが、Linuxカーネルを超えて拡張すると私が思う非常に重要なルールを説明しています：それが人々が依存するバグである場合、それはバグではなく、機能であり、続行するだけです。

システム全体の中で最もコアなライブラリが、物事が「改善」され、ABIが「修正」される限り、問題が発生しても問題がないのは本当に悲しいことです。

そして、サロゲートについて心配する必要がないことは確かに一種の機能であり、ユーザーはあちこちで不注意なsubstring(0, 1)実行してインポートされた関数を呼び出すことができます。または、 split("")を渡して、もう一度join()作成するか、 StringBuilderをモジュールとして作成します。これにより、魔法のように二重置換文字が生成されることはありません。 つまり、非常に人気のある多くの言語が整形式の強制に反対する理由があり、Wasmがこれらの言語とそのユーザーを適切にサポートしたい場合、Wasmがモジュール化されるほど、境界が大きくなります。関数がどのモジュールに存在するかを判断するのが難しくなり、問題がより明らかになります。

現在の現実を無視する方法で何かを設計することが悪い考えであることを証明するためにどれだけ多くの証拠が必要か、私は本当に知りません。 実際、これはインターフェイスタイプでのみ問題ないようですが、他のすべての提案は非常に高い水準に保たれています。 私はこれに関する専門家ではありませんが、USVを主張することによってUCS-2言語のニーズに関してこれとまったく同じ間違いを犯したのは、Unicode標準自体であり、約10年分の同様に絶望的な結果につながったと思います。議論（スレッド全体を推奨できますが、特に沈黙する前の最後のコメント）は、2014年に、WTF-8エンコーディングである一般的に適用される実用的なソリューションの説明で最高潮に達しました。

ビットストリームで文字エンコードエラーが発生したときに置換文字を発行することは、危険なサイレントデータの破損のよく知られた形式であり、整合性を必要とするシステムはそれを禁止していることに注意してください。

関連して、codePointAtが単独のサロゲートをヒットしたときに例外をスローする場合、誰かが誤ってデータベース内の文字列の間違った位置に絵文字を配置したために、アプリケーション全体を壊すバグが発生する可能性があります。

残念ながら、ecmascriptを使用すると、ペアになっていない代理コードポイントを含む文字列を生成しないようにすることが非常に困難になります。文字列から最初の157 .length単位を取得し、「...」を追加して短縮するのと同じくらい簡単です。 また、BMP以外のキャラクターはまれであるため、実際にそれが実際に発生した場合、それは異常な事故です。 Unicodeの衛生状態を改善することを期待して、危険を導入することには非常に消極的です。

JS、Java、C＃が文字列を持っている理由は、Unicodeが2バイトでは不十分であり、UCS-2が実行可能ではないことに気付いたときまでに、大量のコードがすでに記述されていたため、これらの言語は単純に記述していなかったためです。選択肢はありません。 同様に、ユーザースペースに公開されているLinuxシステムコールの場合。 対照的に、ITで定義されたAPIを使用するコードは現在存在しないため、同じ下位互換性要件はありません。 多くの理由で、wasmおよびInterface Typesは、既存の単一言語またはsyscallABIを完全にエミュレートしようと意図的にはして

もちろん、コンポーネント内では、文字列は言語に適した方法で表現できることを強調したいので、実際にはAPIのセマンティクスについてのみ説明し

1. サロゲートを渡す必要がない（そして多くの場合意味がない）と信じる理由はたくさんあります
2. カスタムJSAPIバインディングを使用するエスケープハッチは常にあります（Web APIの100％がWeb APIへのJSグルーレスバインディングを持っている必要はありません）

したがって、これらのWTF-16文字列セマンティクスを引き継がなければITが実行可能ではないことを示唆する証拠はまだないと思います。これは、MVPにとって適切な質問だと思います。

私が同意しないいくつかの点：

あなたの言っていることがinterface-types /＃135で発生した問題にどのように対処しているかわかりません

これは現在別の問題であり、私が損失を解決するための合理的な妥協案であると私が信じていることについて話す前の投稿で。 特に、別の問題であなたの推論に問題はありませんが、ロスレスフォールバックが利用可能な場合に限ります。 これはどちらか/または私の意見ではありません。 そうでない場合は、WTF-8 / 16がより包括的で制限の少ない選択肢であり、Wasmの高レベルの目標の1つがWebプラットフォームとシームレスに統合することであり、それぞれ下位を維持することであるため、私は意見を残します。 -Webの互換性。これは、インターフェイスタイプにも適用されます。

既存のJSAPIは、境界で任意の値の変換を行うための汎用エスケープハッチをすでに提供しているため、この初期の時点で2番目のエスケープハッチがどのように必要かはわかりません。

カスタムJSAPIバインディングを使用するエスケープハッチは常にあります

残念ながら、これは私たちの場合には十分ではありません。現在、次のようなグルーコードがあります。

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を重視しているため、UTF-16LE用のV8のTextDecoderは、他のエンジンよりもはるかに遅いことがわかりました（SMは非常に高速です）。したがって、 String.fromCharCodeは実際には、V8では特定の損益分岐点まで高速です。 そこで、今のところそれを中心に最適化することにしました。 次に、WTF-16にはTextDecoderが存在しないため（これは個別に煩わしい）、最初に整形式のUTF-16をデコードしようとします。それが失敗した場合は、スローしてチャンクスルーにフォールバックします。はるかに遅いString.fromCharCode 。 スタックをオーバーフローさせる可能性があるため、長い文字列にString.fromCharCodeを単純に適用することはできないため、チャンク化が必要です。

一方、たとえばRustはこれを必要としないでしょう。これが、現在のITが本来あるべきほど中立ではないと私が考える理由の1つです。 一般的に、IT stringのポイントは、確かにJSとうまくインターフェースできることだと思います。これは、依然として私たちの主要な相互運用ターゲットです。

現在、ITで定義されたAPIを使用するコードは存在しないため、同じ下位互換性要件はありません。

ITはまだ存在しないため、前半は技術的には真実ですが、IIUCの要件には、たとえば上記のグルーコードの不器用なチャンクの説明など、既存のユースケースの改善が含まれます。 できるだけ多くの言語に理想的であるため、プレゼンテーションで述べたように、ポストMVPは確かに「単なる最適化」になります。 それどころか、今のところITは基本的に、UTF-8エンコーダー/デコーダーを利用できる言語の最適化であるものから始まりますが、これは中立ではないと思います。

wasmおよびInterfaceTypesは、既存の単一言語またはsyscallABIを完全にエミュレートしようと意図的にはしていません。

私はこれを私がこの意見であるかのように読みましたが、私はまったくそうではありません。 私はここで疑いの恩恵をあなたに与えるつもりですが、私の意見では、ITは現在不必要に制限されており、そのため非常に特定の言語のセットにしかうまく機能しないことを付け加えたいと思います。 それどころか、WTF-8 / 16は、JS文字列にラウンドトリップするため、論理的なデフォルトになると私が予想していたより包括的なエンコーディングです。 ここでは同意しませんが、適切なエスケープハッチがない場合に限ります。 実行可能なロスレスの代替手段が存在し、誰も壊れたり不必要に不利になったりしない場合は、デフォルトの文字列タイプの推論で問題ありません。

サロゲートを渡す必要がない（そして多くの場合意味がない）と信じる理由はたくさんあります

ここでは同意しません。 特に、私のプレゼンテーションやコメントは、まれではあるが、非常に意味のあるものになる可能性があるという合理的な疑いを示していると思います（整合性が必要な場合など）。 Unicodeの衛生状態を改善することを望んでいる危険。」 つまり、可能であれば、Java / C＃/ AS <-> JS、Java / C＃/ AS <->の重要な場合にも機能することが保証されている方法で、正規のABIを設計する必要があると思います。 Java / C＃/ AS。 他のパスでの置き換えはおそらく避けられませんが、少なくとも言語とユーザーには選択肢があり、まれにデフォルトがまだ破られていない場合があります。

これらのWTF-16文字列セマンティクスを引き継ぐことなしにITが実行可能ではないことを示唆する証拠はまだないと思います

合理的な疑いがあり、合理的な妥協案であると私が信じていることを探求する意欲がない場合、立証責任はあなたにあると思います。 繰り返しになりますが、私はデフォルトの文字列をあなたと整形式の未来に任せたいと思っていますが、まれではあるがそれでも危険を考慮しないという犠牲を払うことはありません。 多くの人気のある言語はこれによって影響を受ける可能性があり、それらが認識されると、将来的にそれを正当化するのは非常に困難になる可能性があります。

JSグルーコードは理想的ではないことに同意しますが、その正しい修正はJS APIまたはJSにあり、将来のコンポーネントエコシステム全体にwtf-16-stringの概念を追加することではないと思います。 それを超えて、まだ応答されていない応答する新しい情報は表示されません。 目標/範囲の質問についてはほとんど意見が分かれているようです。

TextDecoder異常は、JSで修正するのがさらに難しいと思います。これは、これが範囲外であるとすでに判断されているためです。 JSのTextDecoderは、2つの関数呼び出しの間に呼び出されるものではなく、主にネットワーク経由またはストレージからデータを取得するために使用されるため、JSはそれを行うことができます。

さらに興味深い異常が、そこにもないことを、しかし、であるTextEncoder UTF-16LEのために、その1が関係しています。

/** 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が渡された場合でも、これらの両方が必要になります。 そして、この問題のコンテキストでは、同じ言語の2つのモジュール間の二重の再エンコード+損失はそれほど変わらないという点で、JSAPIに限定されません:(

Webでそのユースケースに対処する方法については、 TextEncoder / TextDecoder以外にもさまざまなオプションがあります。 もう1つは、 new WebAssembly.Function() （一部のブラウザーで既に実装されています）を拡張して、コンストラクターにオプションのパラメーターを追加することで文字列変換を実行することです。 このようなアプローチにより、コンポーネント以外のwasmの使用にも機能が利用できるようになり（場合によってははるかに早く）、JSAPIがこのユースケースに対処するのに適切な場所になるという点が強調されます。

参考：https： //github.com/WebAssembly/interface-types/issues/135#issuecomment-863493832で出てきた「IntegratedW / UTF-any」オプションを上記の提案の