Design: Diskusi: WebAssembly, Unicode dan Platform Web

Mungkin beberapa solusi potensial yang saya kumpulkan dari umpan balik offline sejauh ini, untuk dipertimbangkan:

Terpisah WTF-16

Dalam Jenis Antarmuka, tentukan:

string   := list char
string16 := list u16

Tentukan paksaan yang diterapkan selama penautan, dengan kasus-kasus berikut:

| Dari | Untuk | Ekspektasi
|------------|------------|-------------
| string | string16 | Enkode ulang dari UTF-8 ke UTF-16
| string16 | string | Enkode ulang dari WTF-16 ke UTF-8 (opsi pengganti)

Pemaksaan memastikan bahwa modul string16 bekerja pada host WASI, masing-masing bahwa modul string dan string16 dapat berinteraksi satu sama lain, bahkan jika keduanya string dan modul string16 atau host memanggil ekspor string atau string16 , yang sebaliknya akan menjadi ambigu.

Yang ini juga memperkenalkan ambiguitas dalam penyematan Web karena meneruskan list u16 ke JS bisa menjadi Uint16Array atau DOMString . Pemaksaan seluruh JS dari Uint16Array hingga DOMString tampaknya tidak diinginkan, tetapi tipe JS dapat diisyaratkan dengan secara eksplisit menggunakan alias string16 (dengan id binernya sendiri, string16 :> list u16 murni semantik jika diperlukan) alih-alih list u16 dalam modul adaptor. Makanya alias. Dalam hal ini, string16 akan menjadi DOMString sedangkan list u16 akan menjadi Uint16Array .

Saya tidak terlalu terikat dengan nama string16 dan akan baik-baik saja dengan nama lain, atau alternatif apa pun yang tidak memerlukan nama / id untuk menyelesaikan ambiguitas.

Pengoptimalan yang mirip dengan list.is_canon tidak diperlukan di sini, karena list.count dapat digunakan. Selain itu, pintu menuju UTF-any dan pengoptimalan Latin1 potensial, seperti di bawah ini, dapat tetap terbuka dengan memesan ruang untuk segera di masa mendatang dalam instruksi adaptor list.*_canon .

UTF-apa saja

Dalam Jenis Antarmuka, tentukan:

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)

Solusi potensial ini dapat dipertimbangkan di mana pembentukan yang baik diperlukan. Ini akan menghindari overhead pengkodean ulang ganda dan efek tidak langsung pada ukuran kode, tetapi meninggalkan masalah pengganti yang belum terselesaikan. Perhatikan bahwa $unit 1-3 dapat ditambahkan pasca-MVP sebagai pengoptimalan lebih lanjut, atau kami dapat segera memulai dengan beberapa di antaranya.

WTF-apa saja

Dalam Jenis Antarmuka, tentukan:

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)

Solusi potensial ini juga akan memerlukan pendefinisian ulang char dari Unicode Scalar Values ​​ke Unicode Code Points, sementara membatasi daftar char agar tidak berisi pasangan pengganti (tetapi mengizinkan pengganti yang terisolasi), berpotensi diberlakukan saat mengangkat. Sekali lagi, beton $unit s dalam MVP dapat diperdebatkan.

Yang ini tidak memperkenalkan lossiness sendiri, jadi yang lainnya memang hanya menjadi optimasi pasca-MVP.

Terintegrasi W/UTF-apa saja

Dalam tipe Antarmuka, tentukan:

• Angkat "daftar Poin Kode Unicode yang mengubah pasangan pengganti" tetapi turunkan "daftar Nilai Skalar Unicode". Ini adalah perubahan desain non-fungsional saja jika hanya diterapkan selama pengangkatan 16-bit.
• Tambahkan opsi opsional passthrough saat menurunkan untuk mendapatkan "daftar Poin Kode Unicode". Ini adalah tambahan fungsional yang memungkinkan passthrough tanpa kehilangan.

Dengan demikian kita mencapai:

• Formasi yang baik secara default
• Encoding lossless untuk bahasa WTF sebagai opsi
• Ketika digabungkan dengan https://github.com/WebAssembly/interface-types/issues/136#issuecomment -861799460: Encoder bawaan untuk sebagian besar (semua?) bahasa yang ingin kami dukung dengan baik

IIUC, akar masalahnya adalah bahwa TI ingin string menjadi urutan titik kode unicode tetapi beberapa bahasa menganggap string sebagai urutan nilai i8 atau i16 yang mungkin atau mungkin tidak sesuai dengan string unicode yang terbentuk dengan baik. Salah satu solusi sederhana adalah memiliki bahasa/API yang menerima atau menghasilkan string unicode yang tidak valid menggunakan (list u8) atau (list u16) (mungkin dengan beberapa alias yang bagus seperti byte_string untuk mengomunikasikan maksud) daripada tipe IT string , yang mana IIRC merupakan alias untuk (list char) . Apakah trade off dari melakukan itu sudah dibahas di mana saja?

Saya pikir masalahnya sedikit lebih bernuansa, karena TI ingin mendefinisikan char sebagai "Nilai Skalar Unicode", yang memiliki lubang di mana titik kode pengganti akan berada, dan karena itu tidak dapat mewakili pengganti yang terisolasi . WTF, di sisi lain, adalah "Poin Kode Unicode" tanpa batasan ini, tetapi urutan dibatasi untuk tidak mengandung pasangan titik kode pengganti (ini akan diganti dengan poin kode tambahan > U+FFFF, sementara pengganti yang terisolasi OK). Apakah ini yang kamu maksud?

Selain itu, saya pikir string byte seperti C pada const char* yang bisa apa saja belum dibahas. Saya mungkin telah melewatkannya, meskipun.

Salah satu solusi sederhana adalah memiliki bahasa/API yang menerima atau menghasilkan string unicode yang tidak valid menggunakan (list u8) atau (list u16) (mungkin dengan beberapa alias yang bagus seperti byte_string untuk mengomunikasikan maksud) daripada tipe IT string , yang mana IIRC merupakan alias untuk (list char) .

Saat ini solusi pilihan saya juga - tipe wtf16string akan menjadi alias untuk (list u16) dengan cara yang sama seperti string saat ini didefinisikan sebagai alias untuk (list char) . Nilai alias IIUC adalah bahwa hasil dari fungsi yang mengembalikan (list u16) dipanggil oleh (misalnya) JS akan muncul sebagai daftar JS (angka), sedangkan hasil dari fungsi yang mengembalikan wtf16string dapat ditentukan sebagai muncul di JS sebagai string JS.

Menambahkan alias wtf16string ke draf ABI kanonik tampaknya relatif tidak mengganggu.

WTF, di sisi lain, adalah "Poin Kode Unicode" tanpa batasan ini, tetapi urutan dibatasi untuk tidak mengandung pasangan titik kode pengganti (ini akan diganti dengan poin kode tambahan > U+FFFF, sementara pengganti yang terisolasi OK).

Ah, apakah itu berarti WTF-8 tidak sama dengan (list u16) karena memiliki batasan tambahan ini? Saya tidak menghargai nuansa itu. Intuisi saya adalah bahwa akan berlebihan untuk memiliki tipe string mewakili urutan nilai skalar unicode yang terbentuk dengan baik serta tipe wtf16string yang hampir (list u16) tetapi memiliki batasan tambahan. Apakah menggunakan alias untuk (list u16) tidak terbatas berfungsi cukup baik untuk sistem yang tidak menerapkan unicode dengan baik? Ini catatan di WTF-8 spek menunjukkan bahwa itu akan.

Ah, apakah itu berarti WTF-8 tidak sama dengan plain (daftar u16) karena memiliki batasan penambahan ini?

Ini menyatakan "Seperti UTF-8 secara artifisial dibatasi pada teks Unicode untuk mencocokkan UTF-16, WTF-8 secara artifisial dibatasi untuk mengecualikan pasangan titik kode pengganti untuk mencocokkan UTF-16 yang berpotensi cacat." Iiuc, ia memperlakukan ini sama dengan bagaimana UTF-8 memperlakukan urutan byte yang terlalu panjang atau terpotong. WTF-8 dapat mewakili (list u16) , tetapi tidak setiap (list u8) adalah WTF-8 yang valid.

Apakah menggunakan alias untuk tidak terbatas (daftar u16) berfungsi cukup baik untuk sistem yang tidak menerapkan unicode dengan baik?

WTF-16 memetakan 1:1 ke nilai u16 acak dan itu hanya tergantung pada bagaimana nilai-nilai ini ditafsirkan, jadi ya, (list u16) akan berfungsi.

IIUC, WTF-8 tidak persis sama dengan arbitrer list u8 . Misalnya, melarang "urutan byte pasangan pengganti" (lihat di sini ).

Namun, WTF-16 _is_ sama dengan list u16 . Agak aneh bahwa mereka berbagi tema penamaan.

EDIT: seharusnya disegarkan :)

Saya memposting pertanyaan/jawaban pertama yang berfokus hanya pada pertanyaan pengganti di interface-types/#135 . Saya pikir itu adalah urutan tinggi dan, jika kita dapat menyetujuinya, maka diskusi selanjutnya tentang mendukung satu atau lebih format pengkodean akan lebih sederhana.

Terima kasih, Lukas.

Jika Anda bersedia mendukung "WTF-16 Terpisah" seperti di atas (pemaksaan sangat penting untuk mengaktifkan mengakses API WASI dan untuk berinteraksi dengan JavaScript tanpa kode lem), saya akan merasa nyaman dengan char disarankan rentang nilai. Bahasa WTF-16 kemudian akan memiliki jalan keluar yang mereka butuhkan untuk mengintegrasikan serta mendapatkan modul yang ditulis dalam bahasa yang sama, JavaScript dan melalui penggantian dengan bahasa UTF-*. Saya juga merasa jauh lebih baik tentang WASI btw, karena titik sakit utama yang diperkenalkan oleh ketidakcocokan pengkodean string akan diselesaikan dengan paksaan di tempat.

Memiliki tipe string16 seperti yang Anda sarankan dengan pengganti masih akan memiliki semua masalah dengan pengganti yang diuraikan dalam interface-types/#135 , jadi saya pikir tidak akan lebih baik untuk memiliki dua tipe string vs .satu (terutama jika mereka secara implisit dapat dikonversikan; maka mereka bukan tipe yang terpisah secara bermakna). Memiliki dua jenis string juga akan memperburuk keadaan dengan memperkenalkan beban mental pada setiap desainer antarmuka dan konsumen ("mengapa ada dua jenis? apa bedanya? kapan saya harus menggunakan satu atau yang lain?"). Terakhir, menambahkan dukungan untuk WTF-16 umumnya akan bertentangan dengan panduan evolusi standar masa depan Web/IETF yang juga disebutkan dalam interface-types/#135 . Jadi, saya tidak berpikir kita harus mempertimbangkan untuk menambahkan jenis bantalan pengganti kecuali kita memiliki bukti nyata yang nyata bahwa Jenis Antarmuka tidak layak tanpanya.

Untuk kasus penggunaan Web-eksklusif, saya pikir masuk akal untuk menyelesaikan masalah di JS atau Web API. Misalnya, mudah untuk membayangkan JS API untuk "mengikat" impor dan ekspor wasm. Ini sudah merupakan pendekatan yang diambil di JS API lain yang muncul, seperti stack-switching, dan saya bertanya-tanya apakah yang akan kita tuju adalah API JS "bind import"/"bind export" umum yang mampu menangani Web -kasus khusus dari Janji, string JS, dan tampilan array yang diketik.

Memiliki tipe string16 terpisah seperti yang Anda sarankan dengan pengganti masih akan memiliki semua masalah dengan pengganti yang diuraikan dalam tipe antarmuka/135

Secara teknis benar, tetapi juga melewatkan bahwa string setidaknya akan selalu bekerja di antara modul yang dikompilasi secara terpisah dalam bahasa yang sama, bahasa apa pun yang kompatibel, dan JavaScript, bahkan tanpa pengetahuan sebelumnya tentang jenis modul apa yang digunakan untuk berinteraksi. Itu biasanya sebagian besar kasus saya pikir. Karena itu sepertinya kompromi yang masuk akal bagi saya, juga karena memungkinkan mendedikasikan rentang nilai char diinginkan ke string yang terbentuk dengan baik (USV).

Memiliki dua tipe string juga akan memperburuk keadaan dengan memperkenalkan beban mental pada setiap desainer antarmuka dan konsumen ("mengapa ada dua tipe? apa bedanya? kapan saya harus menggunakan satu atau yang lain?")

Alternatif kerusakan sesekali tampaknya jauh lebih buruk bagi saya, jadi jika itu yang diperlukan, saya pikir kebanyakan orang akan baik-baik saja dengan itu. Mungkin nama yang bagus untuk tipe string kedua ( domstring ?), cukup untuk mengurangi masalah kecil ini.

Terakhir, menambahkan dukungan untuk WTF-16 umumnya akan bertentangan dengan panduan evolusi standar masa depan Web/IETF

Sayangnya, dengan tidak adanya jalan keluar untuk bahasa yang terpengaruh, tidak masalah bagi saya seberapa masuk akal alasan seseorang tentang tren yang diakui, karena selama IT MVP akan memecahkan sesuatu di suatu tempat untuk seseorang, dan sebagian besar tidak berguna untuk bahasa seperti JavaScript yang sedang saya kerjakan, saya hanya bisa menentangnya.

Oleh karena itu saya mencoba untuk menemukan solusi yang masuk akal atau kompromi yang dapat diterima semua orang, dan saya akan senang jika kita dapat bekerja sama.

Saya tidak melihat bagaimana apa yang Anda katakan mengatasi masalah yang diangkat dalam tipe antarmuka/#135 atau memberikan bukti tandingan bahwa TI tidak akan layak secara umum tanpa dimasukkannya tipe domstring . JS API yang ada sudah menyediakan pintu keluar tujuan umum untuk melakukan konversi nilai arbitrer pada batas, jadi saya tidak melihat bagaimana pintu keluar kedua diperlukan pada titik awal ini. Saya pikir kita hanya membutuhkan lebih banyak bukti berbasis pengalaman untuk melawan panduan kuat yang telah kita berikan terhadap string propagasi lebih lanjut yang mengandung pengganti.

(FWIW, Jika kita dapat menyepakati tidak adanya pengganti, saya pikir masuk akal untuk berbicara tentang mendukung U TF-16 sebagai pengkodean tambahan dalam ABI kanonik string . Tapi itu topik yang sama sekali terpisah dengan beberapa opsi, jadi saya tidak ingin mencampurnya dengan semantik string abstrak yang perlu dipahami terlebih dahulu.)

Saya menghargai paragraf kedua Anda, karena itu sudah menyelesaikan beberapa masalah yang sangat mengganggu. Saya setuju bahwa mendukung UTF-16 berguna secara terpisah, dan saya akan menghargai itu ditambahkan ke penjelajah / MVP. Hitung saya!

Namun, saya mengalami kesulitan untuk mengikuti argumen Anda di paragraf pertama. Mungkin jika Anda tidak percaya, inilah Linus Torvalds yang menjelaskan aturan yang sangat penting yang menurut saya melampaui kernel Linux: Don't break userspace . Dan inilah dia dalam pembicaraan yang sama, menjunjung tinggi kebijaksanaan programmer Jika itu adalah bug yang diandalkan orang, itu bukan bug, itu fitur , hanya untuk melanjutkan:

Sangat menyedihkan ketika sebagian besar perpustakaan inti di seluruh sistem baik-baik saja dengan memecahkan barang-barang selama hal-hal "meningkatkan" dan mereka "memperbaiki" ABI.

Dan tidak perlu khawatir tentang pengganti memang semacam fitur, di mana pengguna dapat melakukan substring(0, 1) sembarangan di sini atau di sana dan memanggil fungsi yang diimpor dengannya, atau dapat split("") , meneruskan dan join() lagi, atau buat StringBuilder sebagai modul yang kadang-kadang tidak akan menghasilkan karakter pengganti ganda seolah-olah itu ajaib. Maksud saya, ada alasan mengapa sekelompok bahasa yang sangat populer memilih untuk tidak menerapkan kemapanan yang baik, dan ketika Wasm ingin mendukung bahasa-bahasa ini dan penggunanya dengan baik, maka Wasm yang lebih modular menjadi, semakin banyak batasan, semakin semakin sulit untuk mengetahui di modul mana suatu fungsi hidup, dan semakin jelas masalahnya.

Saya benar-benar tidak tahu berapa banyak lagi bukti yang saya perlukan untuk membuktikan bahwa merancang sesuatu dengan cara yang mengabaikan kenyataan saat ini adalah ide yang buruk. Sebenarnya, ini tampaknya OK saja di Jenis Antarmuka, sementara kami menjaga setiap proposal lain dengan standar yang sangat tinggi. Dan sementara saya bukan ahli dalam hal ini, saya pikir itu adalah standar Unicode itu sendiri yang membuat kesalahan yang sama persis sehubungan dengan kebutuhan bahasa UCS-2 dengan bersikeras pada USV, yang mengarah ke sekitar satu dekade yang sama putus asanya. diskusi (dapat merekomendasikan seluruh utas, tetapi terutama komentar terakhir sebelum diam), pada tahun 2014 yang berpuncak pada deskripsi solusi praktis yang umum diterapkan yaitu pengkodean WTF-8.

Perhatikan bahwa memancarkan karakter pengganti saat menghadapi kesalahan pengkodean karakter dalam bitstream adalah bentuk yang terkenal dari korupsi data diam berbahaya dan sistem yang memerlukan integritas melarang melakukan itu.

Terkait, jika codePointAt akan mengeluarkan pengecualian saat memukul pengganti tunggal, Anda mungkin akan berakhir dengan bug yang merusak seluruh aplikasi Anda karena seseorang secara tidak sengaja menempatkan karakter emoji di posisi yang salah dalam string dalam database

Sayangnya ecmascript membuatnya sangat sulit untuk memastikan Anda tidak menghasilkan string dengan titik kode pengganti yang tidak berpasangan di suatu tempat di dalamnya, semudah mengambil 157 unit .length pertama dari sebuah string dan mungkin menambahkan "..." untuk menyingkatnya. Dan itu adalah kecelakaan yang aneh jika itu benar-benar terjadi dalam praktik karena karakter non-BMP jarang terjadi. Kita harus sangat enggan untuk memperkenalkan bahaya dengan harapan dapat meningkatkan kebersihan Unicode kita.

Alasan JS, Java dan C# memiliki string yang mereka lakukan adalah bahwa, pada saat Unicode menyadari bahwa 2 byte tidak cukup dan dengan demikian UCS-2 tidak layak, banyak kode sudah ditulis, jadi bahasa-bahasa ini tidak melakukannya. tidak punya pilihan. Demikian pula untuk syscalls Linux yang diekspos ke ruang pengguna. Sebaliknya, saat ini tidak ada kode yang menggunakan API yang ditentukan dalam TI, jadi kami tidak memiliki persyaratan kompatibilitas mundur yang sama. Untuk berbagai alasan, Wasm dan Tipe Antarmuka sengaja tidak berusaha untuk meniru dengan sempurna bahasa tunggal atau syscall ABI yang ada. Ini mungkin tujuan yang valid, tetapi itu akan menjadi proyek/standar/lapisan terpisah dari model komponen. Inilah manfaat dari layering dan scoping: kita tidak membutuhkan satu hal yang dapat mencapai semua tujuan yang mungkin.

Saya ingin menekankan kembali bahwa tentu saja di dalam sebuah komponen, string dapat direpresentasikan dengan cara apa pun yang sesuai dengan bahasa tersebut, jadi kita benar-benar hanya berbicara tentang semantik APIs . Adapun Web API yang sudah ditentukan:

1. kami memiliki banyak alasan untuk percaya bahwa tidak perlu (dan seringkali tidak berarti) untuk memberikan pengganti
2. selalu ada jalan keluar untuk menggunakan pengikatan JS API khusus (ini bukan persyaratan bahwa 100% API Web memiliki pengikatan JS-kurang lem ke API Web)

Jadi, saya masih tidak berpikir kami memiliki bukti yang menunjukkan bahwa TI tidak akan layak tanpa meneruskan semantik string WTF-16 ini, yang menurut saya merupakan pertanyaan yang tepat untuk MVP.

Beberapa poin yang saya tidak setuju:

Saya tidak mengerti bagaimana apa yang Anda katakan mengatasi masalah yang diangkat dalam tipe-antarmuka/#135

Ini adalah masalah terpisah sekarang, dan di pos sebelumnya saya berbicara tentang apa yang saya yakini sebagai kompromi yang masuk akal untuk menyelesaikan kerugian. Secara khusus, saya akan setuju dengan alasan Anda dalam masalah terpisah, tetapi hanya jika tersedia fallback lossless. Ini bukan salah satu/atau menurut saya. Jika tidak, saya akan tetap berpendapat bahwa WTF-8/16 adalah pilihan yang lebih inklusif, kurang terbatas, dan karena itu lebih disukai, juga karena salah satu tujuan tingkat tinggi Wasm adalah untuk berintegrasi secara mulus dengan platform Web masing-masing mempertahankan mundur - sifat Web yang kompatibel, dan itu juga berlaku untuk Jenis Antarmuka.

JS API yang ada sudah menyediakan pintu keluar tujuan umum untuk melakukan konversi nilai arbitrer pada batas, jadi saya tidak melihat bagaimana pintu keluar kedua diperlukan pada titik awal ini.

selalu ada jalan keluar dari penggunaan binding JS API khusus

Sayangnya ini tidak cukup dalam kasus kami, di mana saat ini kami memiliki kode lem seperti:

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

Pertama, karena kami sangat peduli dengan Chrome dan Node.js, kami menemukan bahwa TextDecoder V8 untuk UTF-16LE jauh lebih lambat daripada di mesin lain (SM sangat cepat), jadi String.fromCharCode adalah sebenarnya lebih cepat di V8 hingga titik impas tertentu. Jadi kami memutuskan untuk mengoptimalkannya untuk saat ini. Selanjutnya, tidak ada TextDecoder untuk WTF-16 (yang secara terpisah mengganggu), jadi pertama-tama kami mencoba memecahkan kode UTF-16 yang terbentuk dengan baik, dan jika gagal, kami membiarkannya melempar dan jatuh kembali ke chunking through jauh lebih lambat String.fromCharCode . Potongan diperlukan karena seseorang tidak bisa begitu saja menerapkan String.fromCharCode pada string yang panjang, karena kemungkinan besar akan membanjiri tumpukan.

Di sisi lain, Rust, misalnya, tidak membutuhkan ini, yang merupakan salah satu alasan mengapa saya berpikir bahwa TI saat ini tidak senetral yang seharusnya. Secara umum menurut saya inti dari IT string s memang untuk dapat berinteraksi dengan JS dengan baik, yang masih menjadi target interop utama kami.

tidak ada kode saat ini yang menggunakan API yang ditentukan dalam TI, jadi kami tidak memiliki persyaratan kompatibilitas mundur yang sama

Paruh pertama secara teknis benar, karena TI belum ada, tetapi IIUC persyaratan kami mencakup peningkatan kasus penggunaan yang ada, seperti misalnya menghitung potongan kode lem yang canggung di atas. Idealnya untuk bahasa sebanyak mungkin, jadi pasca-MVP memang menjadi "hanya pengoptimalan" seperti yang Anda katakan dalam presentasi Anda. Sebaliknya, saat ini TI pada dasarnya dimulai dengan apa yang sudah menjadi optimasi untuk bahasa yang dapat menggunakan encoder/decoder UTF-8, yang menurut saya tidak netral.

wasm dan Jenis Antarmuka sengaja tidak berusaha meniru dengan sempurna bahasa tunggal atau syscall ABI yang ada

Saya membaca ini seolah-olah saya berpendapat demikian, padahal sebenarnya tidak. Saya bersedia memberi Anda manfaat dari keraguan di sini, tetapi ingin menambahkan bahwa menurut saya, TI saat ini tidak perlu dibatasi dan karena itu hanya melayani serangkaian bahasa yang sangat spesifik dengan baik. Sebaliknya, WTF-8/16 adalah pengkodean yang lebih inklusif yang saya harapkan sebagai default logis, juga karena bolak-balik ke string JS. Kami tidak setuju di sini, tetapi hanya dengan tidak adanya pintu keluar yang tepat. Jika alternatif lossless yang layak akan ada, jadi tidak ada yang rusak atau tidak perlu dirugikan, saya akan baik-baik saja dengan alasan Anda tentang tipe string default.

kami memiliki banyak alasan untuk percaya bahwa tidak perlu (dan seringkali tidak berarti) untuk memberikan pengganti

Kami tidak setuju di sini. Secara khusus, saya pikir presentasi dan komentar saya menimbulkan keraguan yang masuk akal bahwa itu mungkin, dalam beberapa kasus, meskipun jarang, sangat berarti (katakan di mana integritas diperlukan), dan saya berpendapat bahwa "Kita harus sangat enggan untuk memperkenalkan bahaya berharap untuk meningkatkan kebersihan Unicode kami." Artinya, jika kita bisa, saya percaya bahwa kita harus merancang ABI kanonik dengan cara yang dijamin berfungsi dalam kasus-kasus penting berikut juga: Java/C#/AS<->JS, Java/C#/AS<-> Java/C#/AS. Penggantian di jalur lain mungkin tidak dapat dihindari, tetapi setidaknya bahasa dan pengguna memiliki pilihan, masing-masing default belum rusak dalam kasus yang jarang terjadi.

Saya masih tidak berpikir kami memiliki bukti yang menunjukkan bahwa TI tidak akan layak tanpa meneruskan semantik string WTF-16 ini

Di hadapan keraguan yang masuk akal dan tidak adanya kemauan untuk mengeksplorasi apa yang saya yakini sebagai kompromi yang masuk akal, saya berharap bahwa beban pembuktian sekarang ada pada Anda. Sekali lagi, saya bersedia menyerahkan string default kepada Anda dan masa depan yang terbentuk dengan baik, tetapi tidak dengan mengorbankan tidak memperhitungkan apa yang mungkin jarang terjadi, tetapi tetap saja, bahaya. Banyak bahasa populer dapat terpengaruh oleh ini, dan itu mungkin menjadi sangat sulit untuk dibenarkan di masa depan begitu mereka menyadarinya.

Saya setuju bahwa kode lem JS tidak ideal, tetapi saya pikir perbaikan yang tepat untuk itu ada di JS API atau di JS, bukan dengan menambahkan konsep wtf-16-string ke seluruh ekosistem komponen masa depan. Di luar itu, saya tidak melihat informasi baru untuk ditanggapi yang belum ditanggapi; sepertinya kita sebagian besar tidak setuju pada pertanyaan tentang tujuan/ruang lingkup.

Saya berharap anomali TextDecoder menjadi lebih sulit untuk diperbaiki di JS, karena tampaknya sudah diputuskan bahwa ini di luar cakupan. Dan JS agak bisa melakukan itu, karena TextDecoder di JS bukanlah sesuatu yang dipanggil di antara dua panggilan fungsi , tetapi sebagian besar digunakan untuk mengambil data melalui jaringan atau dari penyimpanan.

Anomali yang lebih menarik adalah, bagaimanapun, bahkan tidak ada TextEncoder untuk UTF-16LE, jadi kita harus melakukan:

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

Seperti yang Anda lihat, ini adalah masalah utama untuk sesuatu seperti Java, C#, AS, dan lainnya, dan keduanya masih diperlukan ketika list u16 dilewatkan. Dan dalam konteks masalah ini tidak eksklusif untuk JS API, dalam pengkodean ulang ganda + lossiness di antara dua modul dari bahasa yang sama tidak begitu berbeda :(

Ada banyak pilihan selain TextEncoder / TextDecoder untuk cara menangani kasus penggunaan tersebut di Web. Yang lain adalah memperluas new WebAssembly.Function() (yang sudah diterapkan di beberapa browser) untuk melakukan konversi string dengan menambahkan parameter opsional tambahan ke konstruktor. Pendekatan seperti itu juga akan membuat fungsionalitas tersedia untuk penggunaan non-komponen wasm juga (dan berpotensi lebih cepat), memperkuat poin bahwa JS API akan menjadi tempat yang tepat untuk menangani kasus penggunaan ini.

FYI: Menambahkan opsi "Terintegrasi W/UTF-any" yang muncul di https://github.com/WebAssembly/interface-types/issues/135#issuecomment -863493832 ke daftar saran di atas :)