Design: चर्चा: WebAssembly, यूनिकोड और वेब प्लेटफॉर्म

शायद कुछ संभावित समाधान जो मैंने अब तक ऑफ़लाइन फीडबैक से एकत्र किए हैं, विचार के लिए:

अलग 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 निर्यात को कॉल करते हैं, जो अन्यथा अस्पष्ट होगा।

यह वेब एम्बेडिंग में एक अस्पष्टता का भी परिचय देता है जिसमें JS को list u16 करना Uint16Array या DOMString । Uint16Array से DOMString एक JS-व्यापी जबरदस्ती अवांछनीय लगता है, लेकिन JS प्रकार को स्पष्ट रूप से उपनाम string16 का उपयोग करके संकेत दिया जा सकता है (अपनी बाइनरी आईडी के साथ, string16 :> list u16 एक एडेप्टर मॉड्यूल में list u16 बजाय string16 :> list u16 विशुद्ध रूप से शब्दार्थ हो रहा है)। इसलिए उपनाम। इस मामले में, string16 एक DOMString बन जाएगा जबकि list u16 एक Uint16Array बन जाएगा।

मैं विशेष रूप से string16 नाम से जुड़ा नहीं हूं और किसी भी अन्य नाम, या किसी भी विकल्प के साथ ठीक रहेगा जिसे अस्पष्टता को हल करने के लिए नाम/आईडी की आवश्यकता नहीं है।

यहां list.is_canon समान अनुकूलन आवश्यक नहीं है, क्योंकि list.count का उपयोग किया जा सकता है। साथ ही, नीचे दिए गए अनुसार UTF-any और संभावित लैटिन1 अनुकूलन के द्वार को list.*_canon अडैप्टर निर्देशों में तत्काल भविष्य के लिए स्थान आरक्षित करके खुला रखा जा सकता है।

यूटीएफ-कोई भी

इंटरफ़ेस प्रकारों में, परिभाषित करें:

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 को एमवीपी के बाद आगे के अनुकूलन के रूप में जोड़ा जा सकता है, या हम उनमें से कुछ के साथ तुरंत शुरू कर सकते हैं।

डब्ल्यूटीएफ-कोई भी

इंटरफ़ेस प्रकारों में, परिभाषित करें:

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 को यूनिकोड स्केलर वैल्यू से यूनिकोड कोड पॉइंट्स तक पुनर्परिभाषित करने की भी आवश्यकता होगी, जबकि char की सूचियों को सरोगेट जोड़े (लेकिन अलग-थलग सरोगेट की अनुमति) को शामिल नहीं करने के लिए प्रतिबंधित करते हुए, संभावित रूप से उठाने पर लागू किया जाएगा। फिर से, एक एमवीपी में ठोस $unit s बहस योग्य हैं।

यह अपने आप में हानि का परिचय नहीं देता है, इसलिए बाकी सब कुछ वास्तव में सिर्फ एक एमवीपी अनुकूलन बन जाता है।

एकीकृत डब्ल्यू/यूटीएफ-कोई भी

इंटरफ़ेस प्रकारों में, परिभाषित करें:

• लिफ्ट "यूनिकोड कोड बिंदुओं की सूची सरोगेट जोड़े में संशोधन" लेकिन कम "यूनिकोड स्केलर मूल्यों की सूची"। यह एक गैर-कार्यात्मक डिज़ाइन-केवल परिवर्तन है जब केवल 16-बिट उठाने के दौरान लागू किया जाता है।
• "यूनिकोड कोड बिंदुओं की सूची" प्राप्त करने के लिए कम करते समय एक वैकल्पिक passthrough विकल्प जोड़ें। यह एक कार्यात्मक जोड़ है जो दोषरहित पासथ्रू को सक्षम करता है।

ऐसा करने से हम प्राप्त करते हैं:

• डिफ़ॉल्ट रूप से अच्छी तरह से गठित
• एक विकल्प के रूप में डब्ल्यूटीएफ भाषाओं के लिए दोषरहित एन्कोडिंग
• https://github.com/WebAssembly/interface-types/issues/136#issuecomment -861799460 के साथ संयुक्त होने पर: अधिकांश (सभी?) भाषाओं के लिए अंतर्निहित एन्कोडर हम अच्छी तरह से समर्थन करना चाहते हैं

आईआईयूसी, मूल मुद्दा यह है कि आईटी स्ट्रिंग्स को यूनिकोड कोडपॉइंट्स के अनुक्रम बनाना चाहता है लेकिन कुछ भाषाएं स्ट्रिंग्स को i8 या i16 मानों के अनुक्रम के रूप में मानती हैं जो अच्छी तरह से गठित यूनिकोड स्ट्रिंग्स के अनुरूप हो सकती हैं या नहीं। एक आसान समाधान यह होगा कि ऐसी भाषाएं/एपीआई हों जो अमान्य यूनिकोड स्ट्रिंग्स को स्वीकार या उत्पादन करते हैं, इसके बजाय (list u8) या (list u16) (संभवतः कुछ अच्छे उपनामों जैसे byte_string के साथ संवाद करने के लिए) का उपयोग करते हैं। आईटी string प्रकार, जो आईआईआरसी (list char) लिए एक उपनाम है। क्या ऐसा करने के व्यापार बंद पर अभी तक कहीं चर्चा की गई है?

मुझे लगता है कि यह मुद्दा थोड़ा अधिक बारीक है, इसमें आईटी char को "यूनिकोड स्केलर वैल्यू" के रूप में परिभाषित करना चाहता है, जिसमें उनमें एक छेद है जहां सरोगेट कोड पॉइंट होंगे, और इस तरह अलग सरोगेट का प्रतिनिधित्व नहीं कर सकते हैं . दूसरी ओर, डब्ल्यूटीएफ इस प्रतिबंध के बिना "यूनिकोड कोड अंक" है, लेकिन अनुक्रमों को सरोगेट कोड बिंदु जोड़े नहीं रखने के लिए प्रतिबंधित किया जा रहा है (इन्हें पूरक कोड बिंदुओं के साथ प्रतिस्थापित किया जाएगा> यू + एफएफएफएफ, जबकि पृथक सरोगेट ठीक हैं)। क्या यही आपका मतलब है?

इसके अलावा, मुझे लगता है कि सी-जैसे बाइट स्ट्रिंग्स const char* जो कुछ भी हो सकता है, अभी तक चर्चा नहीं की गई है। हो सकता है कि मैंने इसे याद किया हो, हालाँकि।

एक आसान समाधान यह होगा कि ऐसी भाषाएं/एपीआई हों जो अमान्य यूनिकोड स्ट्रिंग्स को स्वीकार या उत्पादन करते हैं, इसके बजाय (list u8) या (list u16) (संभवतः कुछ अच्छे उपनामों जैसे byte_string के साथ संवाद करने के लिए) का उपयोग करते हैं। आईटी string प्रकार, जो आईआईआरसी (list char) लिए एक उपनाम है।

यह वर्तमान में मेरा पसंदीदा समाधान भी है - एक wtf16string प्रकार (list u16) लिए एक उपनाम होगा, उसी तरह string को वर्तमान में (list char) लिए एक उपनाम के रूप में परिभाषित किया गया है। (list u16) (जैसे) JS द्वारा बुलाए गए फ़ंक्शन का परिणाम JS सूची (संख्याओं का) के रूप में दिखाई देगा, जबकि wtf16string लौटने वाले फ़ंक्शन का परिणाम

कैननिकल एबीआई के मसौदे में एक अतिरिक्त wtf16string उपनाम जोड़ना अपेक्षाकृत अविवेकपूर्ण लगता है।

दूसरी ओर, डब्ल्यूटीएफ इस प्रतिबंध के बिना "यूनिकोड कोड अंक" है, लेकिन अनुक्रमों को सरोगेट कोड बिंदु जोड़े नहीं रखने के लिए प्रतिबंधित किया जा रहा है (इन्हें पूरक कोड बिंदुओं के साथ प्रतिस्थापित किया जाएगा> यू + एफएफएफएफ, जबकि पृथक सरोगेट ठीक हैं)।

आह, क्या इसका मतलब यह है कि डब्ल्यूटीएफ -8 एक सादे (list u16) क्योंकि इसमें यह अतिरिक्त प्रतिबंध है? मैंने उस बारीकियों की सराहना नहीं की थी। मेरे अंतर्ज्ञान है कि यह करने के लिए overkill होगा दोनों एक string अच्छी तरह से एक के रूप में के रूप में अच्छी तरह से गठित यूनिकोड अदिश मूल्यों के दृश्यों का प्रतिनिधित्व टाइप wtf16string प्रकार है कि लगभग एक (list u16) लेकिन अतिरिक्त प्रतिबंध हैं। क्या किसी अप्रतिबंधित (list u16) लिए उपनाम का उपयोग करना उन प्रणालियों के लिए पर्याप्त रूप से काम करेगा जो यूनिकोड को अच्छी तरह से लागू नहीं करते हैं? डब्ल्यूटीएफ -8 स्पेक में यह नोट बताता है कि यह होगा।

आह, क्या इसका मतलब यह है कि डब्ल्यूटीएफ -8 एक सादे (सूची u16) के समान नहीं है क्योंकि इसमें यह अतिरिक्त प्रतिबंध है?

इसमें कहा गया है, "जैसे यूटीएफ -8 कृत्रिम रूप से यूटीएफ -16 से मेल खाने के लिए यूनिकोड टेक्स्ट तक सीमित है, डब्ल्यूटीएफ -8 संभावित रूप से खराब गठित यूटीएफ -16 से मेल खाने के लिए सरोगेट कोड पॉइंट जोड़े को बाहर करने के लिए कृत्रिम रूप से प्रतिबंधित है।" Iiuc, यह इनके साथ उसी तरह व्यवहार करता है जैसे UTF-8 लंबे या छोटे बाइट अनुक्रमों का व्यवहार करता है। WTF-8 किसी भी (list u16) प्रतिनिधित्व कर सकता है, लेकिन प्रत्येक (list u8) मान्य WTF-8 नहीं है।

क्या किसी अप्रतिबंधित (सूची u16) के लिए उपनाम का उपयोग करना उन प्रणालियों के लिए पर्याप्त रूप से काम करेगा जो यूनिकोड की सुगठितता को लागू नहीं करते हैं?

WTF-16 मानचित्र 1:1 से यादृच्छिक u16 मानों और यह केवल इस बात पर निर्भर करता है कि इन मानों की व्याख्या कैसे की जाती है, इसलिए हाँ, (list u16) काम करेगा।

IIUC, WTF-8 मनमानी list u8 । उदाहरण के लिए, यह "सरोगेट जोड़ी बाइट अनुक्रम" को मना करता है ( यहां देखें)।

हालांकि, WTF-16 _is_ list u16 जैसा ही है। यह थोड़ा अजीब है कि वे एक नामकरण विषय साझा करते हैं।

संपादित करें: ताज़ा होना चाहिए था :)

मैंने इंटरफ़ेस-प्रकार/#135 में सरोगेट्स के प्रश्न पर केंद्रित पहला प्रश्न/उत्तर पोस्ट किया। मुझे लगता है कि यह उच्च क्रम बिट है और, यदि हम उस पर सहमत हो सकते हैं, तो एक या अधिक एन्कोडिंग प्रारूपों का समर्थन करने पर बाद की चर्चा आसान होगी।

धन्यवाद, ल्यूक।

यदि आप उपरोक्त के रूप में "अलग डब्ल्यूटीएफ -16" का समर्थन करने के इच्छुक हैं (डब्ल्यूएएसआई एपीआई तक पहुंचने और गोंद कोड के बिना जावास्क्रिप्ट के साथ इंटरफेस करने के लिए जबरदस्ती महत्वपूर्ण है), तो मैं सुझाए गए char साथ सहज महसूस करूंगा मूल्य सीमा। तब WTF-16 भाषाओं में एस्केप हैच होगा जिसे उन्हें एकीकृत करने की आवश्यकता होगी और साथ ही इसे उसी भाषा, जावास्क्रिप्ट में लिखे गए मॉड्यूल और UTF- * भाषाओं के साथ प्रतिस्थापन के माध्यम से प्राप्त होगा। मैं WASI btw के बारे में भी बहुत बेहतर महसूस करूंगा, क्योंकि स्ट्रिंग एन्कोडिंग के बेमेल द्वारा पेश किए गए प्रमुख दर्द बिंदु को जगह में जबरदस्ती के साथ हल किया जाएगा।

एक अलग string16 प्रकार होने पर जैसे आप सरोगेट्स के साथ सुझाव दे रहे हैं, तब भी इंटरफ़ेस-प्रकार/# 135 में उल्लिखित सरोगेट्स के साथ सभी समस्याएं होंगी, इसलिए मुझे लगता है कि दो स्ट्रिंग प्रकार बनाम होना बेहतर नहीं होगा एक (विशेषकर यदि वे परोक्ष रूप से अंतर-परिवर्तनीय हैं, तो वे अर्थपूर्ण रूप से अलग प्रकार नहीं हैं)। दो स्ट्रिंग प्रकार होने से प्रत्येक इंटरफ़ेस डिज़ाइनर और उपभोक्ता पर मानसिक बोझ डालने से चीजें और भी बदतर हो जाएंगी ("दो प्रकार क्यों हैं? क्या अंतर है? मुझे एक या दूसरे का उपयोग कब करना चाहिए?")। अंत में, डब्ल्यूटीएफ -16 के लिए समर्थन जोड़ना आम तौर पर भविष्य के मानकों के विकास मार्गदर्शन वेब/आईईटीएफ के खिलाफ होगा जिसका उल्लेख इंटरफेस-प्रकार/#135 में भी किया गया

वेब-अनन्य उपयोग मामलों के लिए, मुझे लगता है कि जेएस या वेब एपीआई में समस्या को हल करना समझ में आता है। उदाहरण के लिए, "बाध्यकारी" wasm आयात और निर्यात के लिए JS API की कल्पना करना आसान है। यह पहले से ही अन्य उभरते जेएस एपीआई में एक दृष्टिकोण है, जैसे स्टैक-स्विचिंग, और मैं सोच रहा हूं कि हम कहां जा रहे हैं सामान्य "बाध्य आयात"/"बाध्य निर्यात" जेएस एपीआई जो वेब को संभालने में सक्षम हैं वादों, JS स्ट्रिंग्स और टाइप किए गए सरणी दृश्यों के विशिष्ट मामले।

एक अलग स्ट्रिंग 16 प्रकार होने से आप सरोगेट्स के साथ सुझाव दे रहे हैं, फिर भी इंटरफ़ेस-प्रकार/135 में उल्लिखित सरोगेट के साथ सभी समस्याएं होंगी

तकनीकी रूप से सच है, लेकिन यह भी याद आती है कि स्ट्रिंग्स कम से कम हमेशा एक ही भाषा में अलग-अलग संकलित मॉड्यूल, किसी भी संगत भाषा, और जावास्क्रिप्ट के बीच काम करेंगे, यहां तक ​​​​कि इस बात की जानकारी के बिना भी कि किस तरह का मॉड्यूल इंटरफेस कर रहा है। मुझे लगता है कि आमतौर पर ज्यादातर मामले यही होते हैं। जैसा कि मेरे लिए एक उचित समझौता की तरह लगता है, क्योंकि यह वांछित char मूल्य सीमा को अच्छी तरह से गठित (यूएसवी) स्ट्रिंग्स को समर्पित करने की अनुमति देता है।

दो स्ट्रिंग प्रकार होने से प्रत्येक इंटरफ़ेस डिज़ाइनर और उपभोक्ता पर मानसिक बोझ डालने से चीजें और भी खराब हो जाएंगी ("दो प्रकार क्यों हैं? क्या अंतर है? मुझे एक या दूसरे का उपयोग कब करना चाहिए?")

कभी-कभार टूटने का विकल्प मेरे लिए बहुत बुरा लगता है, इसलिए यदि ऐसा है तो मुझे लगता है कि ज्यादातर लोग इसके साथ ठीक होंगे। शायद दूसरे स्ट्रिंग प्रकार के लिए एक अच्छा नाम ( domstring ?), इस छोटी सी समस्या को कम करने के लिए पर्याप्त है।

अंत में, डब्ल्यूटीएफ -16 के लिए समर्थन जोड़ना आम तौर पर भविष्य के मानकों के विकास मार्गदर्शन वेब/आईईटीएफ के खिलाफ होगा

दुर्भाग्य से, प्रभावित भाषाओं के लिए एस्केप हैच की अनुपस्थिति में यह मेरे लिए बहुत मायने नहीं रखता है कि किसी की कथित प्रवृत्ति का तर्क कितना सही है, क्योंकि जब तक आईटी एमवीपी किसी के लिए कहीं कुछ तोड़ने जा रहा है, और काफी हद तक बेकार है जावास्क्रिप्ट जैसी भाषा के लिए मैं काम कर रहा हूं, मैं केवल इसका विरोध कर सकता हूं।

इसलिए मैं एक उचित समाधान खोजने की कोशिश कर रहा हूं या हर किसी के साथ समझौता कर सकता हूं, और अगर हम सहयोग कर सकें तो मुझे खुशी होगी।

मैं यह नहीं देखता कि आप जो कह रहे हैं वह इंटरफ़ेस-प्रकार/#135 में उठाई गई समस्याओं को कैसे संबोधित करता है या प्रतिवाद प्रदान करता है कि आईटी एक नए domstring प्रकार को शामिल किए बिना सामान्य रूप मजबूत मार्गदर्शन दिया गया है, उसका मुकाबला करने के लिए हमें बस अधिक अनुभव-आधारित साक्ष्य की आवश्यकता है।

(एफडब्ल्यूआईडब्ल्यू, अगर हम सरोगेट्स की अनुपस्थिति पर सहमत हो सकते हैं, तो मुझे लगता है कि यू टीएफ -16 को string के कैननिकल एबीआई में अतिरिक्त एन्कोडिंग के रूप में समर्थन देने के बारे में बात करना समझदारी होगी। लेकिन यह एक अलग विषय है जिसमें कुछ विकल्प, इसलिए मैं इसे अमूर्त स्ट्रिंग शब्दार्थ के साथ मिलाना नहीं चाहता, जिसे पहले समझने की आवश्यकता है।)

मैं आपके दूसरे पैराग्राफ की सराहना करता हूं, जिसमें यह पहले से ही कुछ बहुत ही कष्टप्रद समस्याओं का समाधान करेगा। मैं सहमत हूं कि UTF-16 का समर्थन अलग से उपयोगी है, और मैं इसे व्याख्याता/एमवीपी में जोड़े जाने की सराहना करता हूं। अपनी गतिविधि या योजना में मुझे शामिल करें!

हालाँकि, मुझे पहले पैराग्राफ में आपके तर्कों का पालन करने में कठिनाई हो रही है। शायद अगर आप मुझ पर विश्वास नहीं करते हैं, तो यहां लिनुस टॉर्वाल्ड्स एक बहुत ही महत्वपूर्ण नियम की व्याख्या कर रहे हैं जो मुझे लगता है कि लिनक्स कर्नेल से परे है: उपयोगकर्ता स्थान को मत तोड़ो । और यहाँ वह एक ही बात में है, प्रोग्रामर ज्ञान को कायम रखते हुए अगर यह एक बग है जिस पर लोग भरोसा करते हैं, यह एक बग नहीं है, यह एक विशेषता है , केवल इसके साथ जारी रखने के लिए:

यह वास्तव में दुखद है जब पूरे सिस्टम में सबसे मुख्य पुस्तकालय सामान को तोड़ने के साथ ठीक है जब तक चीजें "सुधार" होती हैं और वे एबीआई को "ठीक" करते हैं।

और सरोगेट्स के बारे में चिंता न करना वास्तव में एक प्रकार की सुविधा है, जिसमें उपयोगकर्ता लापरवाह substring(0, 1) यहां या वहां कर सकते हैं और इसके साथ एक आयातित फ़ंक्शन को कॉल कर सकते हैं, या split("") पास कर सकते हैं और join() फिर से, या एक मॉड्यूल के रूप में StringBuilder बनाएं जो कभी-कभी डबल प्रतिस्थापन वर्ण उत्पन्न नहीं करेगा जैसे कि यह जादू था। मेरा मतलब है, एक कारण है कि बहुत लोकप्रिय भाषाओं के एक समूह ने अच्छी तरह से गठन को लागू करने के खिलाफ चुना, और जब वासम इन भाषाओं और इसके उपयोगकर्ताओं का अच्छी तरह से समर्थन करना चाहता है, तो जितना अधिक मॉड्यूलर वासम बन जाएगा, उतनी ही अधिक सीमा होगी, यह बताना कठिन हो जाएगा कि कोई फ़ंक्शन किस मॉड्यूल में रहता है, और समस्या जितनी अधिक स्पष्ट होगी।

मैं वास्तव में नहीं जानता कि मुझे यह साबित करने के लिए और कितने सबूत चाहिए कि कुछ इस तरह से डिजाइन करना जो वर्तमान वास्तविकता को अनदेखा करता है, एक बुरा विचार है। वास्तव में, यह केवल इंटरफ़ेस प्रकारों में ठीक लगता है, जबकि हम हर दूसरे प्रस्ताव को बहुत उच्च मानकों पर रख रहे हैं। और जबकि मैं इस पर एक विशेषज्ञ नहीं हूं, मुझे लगता है कि यह यूनिकोड मानक ही था जो यूएसवी पर जोर देकर यूसीएस -2 भाषाओं की जरूरतों के संबंध में ठीक यही गलती कर रहा था, जिससे लगभग एक दशक तक इसी तरह की हताशा हुई। चर्चा (पूरे धागे की सिफारिश कर सकते हैं, लेकिन विशेष रूप से चुप होने से पहले आखिरी टिप्पणी), 2014 में डब्ल्यूटीएफ -8 एन्कोडिंग आमतौर पर लागू व्यावहारिक समाधान के विवरण में समाप्त हुआ।

ध्यान दें कि बिटस्ट्रीम में वर्ण एन्कोडिंग त्रुटियों का सामना करते समय एक प्रतिस्थापन चरित्र का उत्सर्जन खतरनाक मूक डेटा भ्रष्टाचार और सिस्टम का एक प्रसिद्ध रूप है जिसके लिए अखंडता की आवश्यकता होती है।

संबंधित रूप से, यदि codePointAt एक अकेला सरोगेट मारते समय एक अपवाद फेंक देगा, तो आप बहुत अच्छी तरह से एक बग के साथ समाप्त हो सकते हैं जो आपके पूरे एप्लिकेशन को तोड़ देता है क्योंकि किसी ने गलती से एक इमोजी चरित्र को एक डेटाबेस में एक स्ट्रिंग में गलत स्थिति में डाल दिया है।

दुर्भाग्य से एक्मास्क्रिप्ट यह सुनिश्चित करना बहुत मुश्किल बना देता है कि आप कहीं न कहीं अप्रकाशित सरोगेट कोड बिंदुओं के साथ तार उत्पन्न नहीं करते हैं, यह एक स्ट्रिंग से पहली 157 .length इकाइयों को लेना और शायद इसे संक्षिप्त करने के लिए "..." जोड़ना जितना आसान है। और यह एक अजीब दुर्घटना है अगर वास्तव में व्यवहार में ऐसा होता है क्योंकि गैर-बीएमपी वर्ण दुर्लभ हैं। हमें अपने यूनिकोड स्वच्छता में सुधार की उम्मीद में खतरों को पेश करने में बहुत अनिच्छुक होना चाहिए।

JS, Java और C# में तार होने का कारण यह है कि, जब तक यूनिकोड ने महसूस किया कि 2 बाइट्स पर्याप्त नहीं थे और इस प्रकार UCS-2 व्यवहार्य नहीं था, कोड का एक गुच्छा पहले से ही लिखा गया था, इसलिए इन भाषाओं ने बस किया कोई विकल्प नहीं है। इसी तरह, Linux syscalls के लिए उपयोगकर्ता स्थान के संपर्क में है। इसके विपरीत, आज कोई कोड मौजूद नहीं है जो आईटी में परिभाषित एपीआई का उपयोग कर रहा है, इसलिए हमारे पास समान पश्च-संगतता आवश्यकताएं नहीं हैं। कई कारणों से, wasm और इंटरफ़ेस प्रकार जानबूझकर मौजूदा एकल भाषा या syscall ABI का पूरी तरह से अनुकरण करने की मांग नहीं कर रहे हैं। यह एक वैध लक्ष्य हो सकता है, लेकिन यह घटक मॉडल की तुलना में एक अलग परियोजना/मानक/परत होगी। यह लेयरिंग और स्कोपिंग का लाभ है: हमें एक ऐसी चीज की आवश्यकता नहीं है जो सभी संभावित लक्ष्यों को प्राप्त करे।

मैं इस बात पर फिर से जोर देना चाहता हूं कि निश्चित रूप से एक घटक के अंदर , स्ट्रिंग्स को भाषा के लिए उपयुक्त तरीके से दर्शाया जा सकता है, इसलिए हम वास्तव में केवल एपीआई के शब्दार्थ के बारे में बात कर रहे

1. हमारे पास यह मानने के बहुत सारे कारण हैं कि सरोगेट पास करना आवश्यक नहीं है (और अक्सर अर्थपूर्ण नहीं)
2. कस्टम जेएस एपीआई बाइंडिंग का उपयोग करने से हमेशा बच निकलता है (यह एक आवश्यकता नहीं है कि वेब एपीआई के 100% वेब एपीआई के लिए जेएस-गोंद-रहित बाध्यकारी हो)

इस प्रकार, मुझे अभी भी नहीं लगता कि हमारे पास कोई सबूत है कि आईटी इन डब्ल्यूटीएफ -16 स्ट्रिंग सेमेन्टिक्स को आगे बढ़ाने के बिना व्यवहार्य नहीं होगा, जो मुझे लगता है कि एमवीपी के लिए उपयुक्त प्रश्न है।

कुछ बिंदु जिनसे मैं असहमत हूं:

मैं नहीं देखता कि आप जो कह रहे हैं वह इंटरफ़ेस-प्रकार/#135 . में उठाई गई समस्याओं का समाधान कैसे करता है

यह अब एक अलग मुद्दा है, और पोस्ट में इससे पहले कि मैं उस बारे में बात कर रहा था जिसे मैं हानि को हल करने के लिए एक उचित समझौता मानता हूं। विशेष रूप से, मैं अलग मुद्दे में आपके तर्क के साथ ठीक रहूंगा, लेकिन केवल तभी जब कोई दोषरहित फ़ॉलबैक उपलब्ध हो। यह या तो/या मेरी राय में नहीं है। यदि नहीं, तो मेरा मानना ​​है कि WTF-8/16 अधिक समावेशी, कम प्रतिबंधित विकल्प है, और इसलिए भी बेहतर है, क्योंकि Wasm के उच्च स्तरीय लक्ष्यों में से एक क्रमशः वेब प्लेटफॉर्म के साथ समेकित रूप से एकीकृत करना है। -वेब की संगत प्रकृति, और यह इंटरफ़ेस प्रकारों पर भी लागू होती है।

मौजूदा जेएस एपीआई पहले से ही सीमाओं पर मनमाना मूल्य रूपांतरण करने के लिए एक सामान्य-उद्देश्य एस्केप हैच प्रदान करता है, इसलिए मुझे नहीं लगता कि इस शुरुआती बिंदु पर दूसरी एस्केप हैच की आवश्यकता कैसे है।

कस्टम 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 की बहुत परवाह करते हैं, इसलिए हमने पाया कि UTF-16LE के लिए V8 का TextDecoder अन्य इंजनों की तुलना में बहुत धीमा है (SM वास्तव में तेज़ है), इसलिए String.fromCharCode है वास्तव में V8 में एक निश्चित ब्रेक ईवन पॉइंट तक तेज़। इसलिए हमने अभी के लिए इसके आसपास अनुकूलन करने का निर्णय लिया है। इसके बाद, WTF-16 (जो अलग से कष्टप्रद है) के लिए कोई TextDecoder मौजूद नहीं है, इसलिए हम पहले अच्छी तरह से गठित UTF-16 को डिकोड करने का प्रयास करते हैं, और यदि यह विफल हो जाता है, तो हम इसे फेंकने देते हैं और वापस चंकिंग के माध्यम से गिर जाते हैं बहुत धीमा String.fromCharCode । चंकिंग आवश्यक है क्योंकि एक लंबी स्ट्रिंग पर केवल String.fromCharCode लागू नहीं किया जा सकता है, क्योंकि इससे स्टैक ओवरफ्लो होने की संभावना है।

दूसरी ओर, उदाहरण के लिए, रस्ट को इसकी आवश्यकता नहीं होगी, जो एक कारण है कि मुझे लगता है कि आईटी, अभी उतना तटस्थ नहीं है जितना होना चाहिए। आम तौर पर मुझे लगता है कि आईटी string s का बिंदु वास्तव में जेएस के साथ इंटरफेस करने में सक्षम होना है, जो अभी भी हमारा प्राथमिक इंटरऑप लक्ष्य है।

आज कोई कोड मौजूद नहीं है जो आईटी में परिभाषित एपीआई का उपयोग कर रहा है, इसलिए हमारे पास समान पश्च-संगतता आवश्यकताएं नहीं हैं

पहली छमाही तकनीकी रूप से सही है, चूंकि आईटी अभी तक मौजूद नहीं है, लेकिन आईआईयूसी हमारी आवश्यकताओं में मौजूदा उपयोग के मामलों में सुधार करना शामिल है, उदाहरण के लिए उपरोक्त गोंद कोड के बेकार हिस्से के लिए लेखांकन। आदर्श रूप से अधिक से अधिक भाषाओं के लिए, इसलिए पोस्ट-एमवीपी वास्तव में "सिर्फ एक अनुकूलन" बन जाता है जैसा आपने अपनी प्रस्तुति में कहा था। इसके विपरीत, अभी आईटी मूल रूप से उन भाषाओं के लिए पहले से ही अनुकूलन के साथ शुरू होता है जो यूटीएफ -8 एन्कोडर/डिकोडर का उपयोग कर सकते हैं, जो मुझे लगता है कि तटस्थ नहीं है।

wasm और इंटरफ़ेस प्रकार जानबूझकर मौजूदा एकल भाषा या syscall ABI का पूरी तरह से अनुकरण करने की मांग नहीं कर रहे हैं

मैंने इसे ऐसे पढ़ा जैसे मैं इस राय का था, जो मैं पूरी तरह से नहीं हूं। मैं आपको यहां संदेह का लाभ देने के लिए तैयार हूं, लेकिन यह जोड़ना चाहूंगा कि मेरी राय में, आईटी वर्तमान में अनावश्यक रूप से प्रतिबंधित है और इस तरह केवल बहुत विशिष्ट भाषाओं के समूह को अच्छी तरह से कार्य करता है। इसके विपरीत, डब्ल्यूटीएफ -8/16 अधिक समावेशी एन्कोडिंग है जिसे मैंने तार्किक डिफ़ॉल्ट होने की उम्मीद की होगी, क्योंकि यह जेएस स्ट्रिंग्स के लिए राउंडट्रिप्स है। हम यहां असहमत हैं, लेकिन केवल एक उचित एस्केप हैच के अभाव में। यदि एक व्यवहार्य दोषरहित विकल्प मौजूद होगा, तो कोई भी टूटा हुआ या अनावश्यक रूप से वंचित नहीं है, मैं डिफ़ॉल्ट स्ट्रिंग प्रकार के आपके तर्क के साथ ठीक रहूंगा।

हमारे पास यह मानने के बहुत सारे कारण हैं कि सरोगेट पास करना आवश्यक नहीं है (और अक्सर अर्थपूर्ण नहीं)

हम यहां असहमत हैं। विशेष रूप से, मुझे लगता है कि मेरी प्रस्तुति और टिप्पणियां उचित संदेह पेश करती हैं कि कुछ मामलों में, हालांकि दुर्लभ, बहुत सार्थक हो सकता है (कहें कि जहां अखंडता की आवश्यकता है), और मेरी राय है कि "हमें परिचय देने में बहुत अनिच्छुक होना चाहिए हमारे यूनिकोड स्वच्छता में सुधार की उम्मीद करने वाले खतरे।" यही है, यदि हम कर सकते हैं, तो मेरा मानना ​​है कि हमें कैननिकल एबीआई को इस तरह से डिजाइन करना चाहिए जो निम्नलिखित महत्वपूर्ण मामलों में भी काम करने की गारंटी है: जावा/सी#/एएस<->जेएस, जावा/सी#/एएस<-> जावा/सी#/एएस. अन्य पथों पर प्रतिस्थापन शायद अपरिहार्य है, लेकिन कम से कम भाषाओं और उपयोगकर्ताओं के पास एक विकल्प है, क्रमशः दुर्लभ मामलों में डिफ़ॉल्ट पहले से ही टूटा नहीं है।

मुझे अभी भी नहीं लगता कि हमारे पास ऐसा कोई सबूत है जो यह बताता हो कि इन WTF-16 स्ट्रिंग सिमेंटिक्स को आगे बढ़ाए बिना IT व्यवहार्य नहीं होगा

उचित संदेह की उपस्थिति में और जो मैं एक उचित समझौता मानता हूं, उसका पता लगाने की इच्छा के अभाव में, मैं उम्मीद करूंगा कि सबूत का बोझ अब आप पर है। फिर से, मैं आपके लिए डिफ़ॉल्ट स्ट्रिंग और एक अच्छी तरह से गठित भविष्य को छोड़ने के लिए तैयार हूं, लेकिन जो दुर्लभ हो सकता है, लेकिन फिर भी, खतरों के लिए लेखांकन नहीं करने की कीमत पर नहीं। कई लोकप्रिय भाषाएँ इससे प्रभावित हो सकती हैं, और भविष्य में एक बार उन्हें इसका औचित्य सिद्ध करना वास्तव में कठिन हो सकता है।

मैं मानता हूं कि जेएस गोंद कोड आदर्श नहीं है, लेकिन मुझे लगता है कि इसके लिए सही फिक्स जेएस एपीआई या जेएस में है, न कि पूरे भविष्य के घटक पारिस्थितिकी तंत्र में wtf-16-string की अवधारणा को जोड़कर। इसके अलावा, मुझे उस पर प्रतिक्रिया देने के लिए नई जानकारी दिखाई नहीं दे रही है जिसका पहले से जवाब नहीं दिया गया है; ऐसा लगता है कि हम ज्यादातर लक्ष्यों/दायरे के सवालों पर असहमत हैं।

मुझे उम्मीद है कि TextDecoder विसंगति को JS में ठीक करना और भी कठिन होगा, क्योंकि यह स्पष्ट रूप से पहले ही तय कर चुका है कि यह दायरे से बाहर है। और जेएस ऐसा कर सकता है, क्योंकि जेएस में TextDecoder ऐसा कुछ नहीं है जिसे दो फ़ंक्शन कॉल के बीच में बुलाया जाता है, लेकिन ज्यादातर नेटवर्क पर या स्टोरेज से डेटा पुनर्प्राप्त करने के लिए उपयोग किया जाता है।

हालांकि, और भी दिलचस्प विसंगति यह है कि UTF-16LE के लिए TextEncoder भी नहीं है, इसलिए किसी को यह करना होगा:

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

जैसा कि आप देख सकते हैं, जावा, सी #, एएस और अन्य जैसे कुछ के लिए यह एक प्रमुख दर्द बिंदु है, और ये दोनों तब भी आवश्यक होंगे जब list u16 पारित हो जाए। और इस मुद्दे के संदर्भ में यह जेएस एपीआई के लिए विशिष्ट नहीं है, उस डबल री-एन्कोडिंग में + एक ही भाषा के दो मॉड्यूल के बीच हानि इतनी अलग नहीं है :(

वेब पर उस उपयोग के मामले को कैसे संबोधित किया जाए, इसके लिए TextEncoder / TextDecoder से परे विकल्पों की एक पूरी जगह है। दूसरा कंस्ट्रक्टर में अतिरिक्त वैकल्पिक पैरामीटर जोड़कर स्ट्रिंग रूपांतरण करने के लिए new WebAssembly.Function() (जो पहले से ही कुछ ब्राउज़रों में लागू है) का विस्तार कर रहा है। इस तरह के दृष्टिकोण से वासम के गैर-घटक उपयोगों के लिए भी कार्यक्षमता उपलब्ध होगी (और संभावित रूप से बहुत जल्द), इस बात को पुष्ट करते हुए कि जेएस एपीआई इस उपयोग के मामले को संबोधित करने के लिए सही जगह होगी।

एफवाईआई: ऊपर दिए गए सुझावों की https://github.com/WebAssembly/interface-types/issues/135#issuecomment -863493832 में आया था :)