Rust: गैर-ASCII पहचानकर्ताओं के लिए ट्रैकिंग समस्या (सुविधा "non_ascii_idents")

/cc @rust-lang/lang

नामांकित

cc @SimonSapin

जाहिरा तौर पर हम इसे लागू करते हैं: http://www.unicode.org/reports/tr31/ या ऐसा कुछ।

मैं इसे स्थिर देखना चाहता हूं, लेकिन खुद को यह समझाने के लिए कुछ काम करना होगा कि हम सही काम कर रहे हैं।

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

@SimonSapin
सी और सी ++ http://unicode.org/reports/tr31/#Alternative_Identifier_Syntax (कुछ मामूली प्रतिबंधों के साथ) का उपयोग करते हैं और मैंने इसके बारे में isocpp फ़ोरम या समस्या सूचियों पर कोई शिकायत नहीं देखी है :)
समस्या का अवलोकन: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1518.htm
क्लैंग में कार्यान्वयन: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/UnicodeCharSets.h?view=markup
सीसी https://github.com/rust-lang/rust/issues/4928

पहचानकर्ताओं के सामान्यीकरण और फ़ाइल सिस्टम नामों (OS X, IIRC पर) में यूनिकोड mod नामों को मैप करने में भी समस्या है, लेकिन मुझे यहां प्रासंगिक लिंक नहीं मिल रहा है: https://github.com /जंग-लंग/जंग/मुद्दों/2253. (सबसे खराब स्थिति में गैर-इनलाइन mod s और extern crate s को ASCII होने के लिए मजबूर किया जा सकता है)

हां #2253 बड़ा मुद्दा है जिसके बारे में मुझे पता है कि मुझे गैर-यूनिकोड पहचानकर्ताओं के समयपूर्व स्थिरीकरण के बारे में चिंता है।

(चर्चा अधिक व्यापक है और तर्कसंगत रूप से दो धागे में फोर्क किया जा सकता है; उदाहरण के लिए हम पहचानकर्ताओं के लिए एक सामान्यीकरण पथ ले सकते हैं और दूसरा स्ट्रिंग शाब्दिक सामग्री के लिए ले सकते हैं।)

हम इस चर्चा को आरएफसीएस रेपो में माइग्रेट करना चाह सकते हैं, उदाहरण के लिए https://github.com/rust-lang/rfcs/issues/802

मैं सहमत हूं कि यह एक विशेषता है जिसे आरएफसी प्रक्रिया के माध्यम से रखा जाना चाहिए।

मैंने इस मुद्दे को non_ascii_idents फीचर गेट के स्थिरीकरण (या बहिष्करण, आदि) को ट्रैक करने के लिए फिर से तैयार किया है।

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

ट्राइएज: पी-लो

कम के रूप में चिह्नित करना क्योंकि वर्तमान में कोई RFC नहीं है और इसलिए कोई कार्रवाई योग्य सामग्री नहीं है।

सीसी https://github.com/rust-lang/rust/issues/7539

जावास्क्रिप्ट, पर्ल 5 और पर्ल 6 में यह सुविधा उपलब्ध है।
जावास्क्रिप्ट (फ़ायरफ़ॉक्स 50)

function Слово(стойност) {
  this.стойност = стойност;
}
var здрасти = new Слово("Здравей, свят");
console.log(здрасти.стойност) //Здравей, свят

पर्ल>=5.12

use utf8;
{
  package Слово;
  sub new {
    my $self = bless {}, shift;
    $self->{стойност} = shift;
    $self
  }
};
my $здрасти = Слово->new("здравей, свят");
say ucfirst($здрасти->{стойност}); #Здравей, свят

Perl6 (यह केवल पर्ल का अगला संस्करण नहीं है। यह एक नई भाषा है)

class Слово {
  has $.стойност;
}

my $здрасти = Слово.new(стойност => 'здравей, свят');
say $здрасти.tc; #Здравей, свят

मुझे इसे रस्ट में भी देखकर खुशी होगी।

ईसीएमएस्क्रिप्ट 2015 में इसके लायक पहचानकर्ता यूनिकोड मानक अनुलग्नक #31 से डिफ़ॉल्ट पहचानकर्ता सिंटेक्स पर आधारित हैं।

use utf8; के साथ पर्ल नीचे दिए गए regexp का उपयोग करता है, XID_Start और XID_Continue के साथ संभवतः UAX # 31 से भी।

/ (?[ ( \p{Word} & \p{XID_Start} ) + [_] ])
        (?[ ( \p{Word} & \p{XID_Continue} ) ]) *    /x

हां! धन्यवाद @SimonSapin!

पायथन के लिए यह <XID_Start> <XID_Continue>* है।

तो ऐसा लगता है कि कई प्रोग्रामिंग भाषाएं गैर-ASCII पहचानकर्ताओं को एक ही मानक पर आधारित होने की अनुमति देती हैं, लेकिन विवरण में वे प्रत्येक कुछ अलग करते हैं ...

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

इस सुविधा का वास्तव में क्या मतलब है? आपके कोड में विभिन्न भाषाओं का वास्तव में बदसूरत मिश्रण बनाने की संभावना जोड़ने के अलावा (अंग्रेजी एकमात्र सही मायने में अंतरराष्ट्रीय भाषा है), यह भाषा की कार्यक्षमता के अनुसार कोई लाभ नहीं देता है। या यह यूनिकोड का समर्थन करने के लिए यूनिकोड का समर्थन है?

@DoumanAsh हर कार्यक्रम अंतरराष्ट्रीय नहीं है, और प्रोग्रामिंग के लिए अंग्रेजी प्रवाह की आवश्यकता नहीं है।

यह किसी भी परियोजना के ठीक अनुरक्षकों के लिए यह तय करना है कि उनके कोड में चर नाम और टिप्पणियां अंग्रेजी में होनी चाहिए। कई ओपन-सोर्स प्रोजेक्ट्स के लिए यही होता है, जिसमें रस्टसी भी शामिल है। लेकिन इसका मतलब यह नहीं है कि भाषा को यहीं तक सीमित रखा जाए।

मैं जो उपयोग केस देखता हूं वह उत्पादन कोड लिखने के लिए नहीं है, बल्कि शिक्षण के लिए है। मैं वास्तव में लोगों को यह बताना चाहता हूं कि प्रोग्रामर बनने के लिए उन्हें अंग्रेजी में धाराप्रवाह होना चाहिए। दूसरी स्थिति यह है कि जब आप एक विदेशी भाषा UI लिख रहे हैं, यदि आपके UI में "příjmení" लेबल वाला टेक्स्ट बॉक्स है, लेकिन आप "अंतिम नाम" नामक एक चर में मान डालते हैं जो अजीब है। यहां तक ​​कि अगर आपके पास "rodné_číslo" (चेक राष्ट्रीय आईडी नंबर) नामक एक फ़ील्ड है तो भी अजीब है। उसके लिए कोई समान अंग्रेजी शब्द नहीं है। तो अगर मैं चेक टैक्स ऐप, या बैंकिंग ऐप लिख रहा था तो मुझे बिना किसी अच्छे कारण के अजीब नाम का उपयोग करना होगा। ऐसा नहीं है कि ऐसा ऐप किसी भी तरह से अन्य भाषाओं के लिए पोर्टेबल होगा।

इसके लिए अनुमति देने का एक और अच्छा कारण यह है कि भाषाविदों को अक्सर चर नामों में आईपीए संकेतन का उपयोग करने की आवश्यकता होती है। आईपीए प्रतीकों के अंग्रेजी नाम बहुत लंबे हो सकते हैं। उदाहरण के लिए, लाल शब्द में अमेरिकी अंग्रेजी r ध्वनि को एक वर्ण के रूप में स्थानांतरित किया जाता है, लेकिन इसे पोस्ट-एल्वियोलर रेट्रोफ्लेक्सिव सन्निकटन नाम दिया गया है। https://en.wikipedia.org/wiki/Alveolar_and_postalveolar_approximants तो अगर मैं एक टेक्स्ट-टू-स्पीच प्रोग्राम लिख रहा हूं तो शायद मैं fn say_post_alveolar_retroflexive_approximant() के स्थान पर fn say_post_alveolar_retroflexive_approximant() fn say_ɹ̠() लिखना चाहता हूं।

चीजों के एक गैर-राय पक्ष पर, मुझे लगता है कि यहां एक दिलचस्प चर्चा होनी है, जिसके संबंध में यूनिकोड कोड बिंदुओं को एक चर नाम का हिस्सा बनने की अनुमति है। उदाहरण के लिए: क्या मैं एक चर price€ नाम दे सकता हूँ? शायद नहीं, मुझे नहीं लगता कि price$ काम करता है? क्या मैं वेक्टर उत्पन्न करने के लिए एक →![] मैक्रो बना सकता हूँ? मुझे पता है कि कोई ऐसा करना चाहेगा, लेकिन → एक "गणित का प्रतीक" है http://www.fileformat.info/info/unicode/char/2192/index.htm । तो जब लेक्सिंग करते हैं, तो हमें यह निर्णय लेने की आवश्यकता होती है कि कौन से कोड पॉइंट स्वीकार्य हैं और कौन से नहीं हैं और शायद जंग को यूनिकोड मानक से चुपचाप नहीं पूछना चाहिए कि कुछ अक्षर है या नहीं।

@timthelion वर्तमान कार्यान्वयन में रस्ट केवल यूनिकोड मानक से विनम्रतापूर्वक नहीं पूछता है कि कुछ अक्षर है या नहीं - यह XID_Start और XID_Continue यूनिकोड गुणों पर निर्भर करता है जिसमें आपके सभी उदाहरणों में सही और सहज व्यवहार होता है।

• say_ɹ̠ की अनुमति है क्योंकि 'ɹ' और '̠' दोनों XID_Continue हैं।
• price€ और price$ की अनुमति नहीं है क्योंकि '€' और '$' XID_Continue नहीं हैं।
• →![] की अनुमति नहीं है क्योंकि '→' XID_Start नहीं है।
• příjmení और rodné_číslo की अनुमति है।

@dtolnay स्पष्टीकरण के लिए धन्यवाद। मुझे आशा है कि आप "बेवकूफ" शब्द के मेरे उपयोग से नाराज नहीं थे, शायद वह एक खराब चुना हुआ शब्द था।

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

मैं अन्य इन-प्रोडक्शन उपयोग मामलों के साथ आ सकता हूं।

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

इस बिंदु पर मुझे लगता है कि इसमें कोई संदेह नहीं है कि हमारे पास कई मामले हैं। क्या करना बाकी है विवरण का पता लगाएं:

• वास्तव में किन पात्रों की अनुमति दी जानी चाहिए। उदाहरण के लिए गैर-ASCII विराम चिह्न को संभवतः बाहर रखा जाना चाहिए।
• कितना सामान्यीकरण किया जाना चाहिए: दो पहचानकर्ताओं को अलग-अलग कोड बिंदुओं (स्रोत फ़ाइलों में अलग-अलग यूटीएफ -8 बाइट्स) के साथ दर्शाया जा सकता है लेकिन फिर भी समकक्ष माना जाता है।

कई अन्य भाषाएं यूनिकोड मानक अनुलग्नक # 31 पर सहमत हैं, लेकिन विवरण में छोटे अंतर हैं। आदर्श रूप से, हम यह पता लगाएंगे कि रस्ट के लिए सबसे अच्छा क्या है, यह तय करने के लिए इन अंतरों ने क्या प्रेरित किया।

https://rosettacode.org/wiki/Unicode_variable_names में कई भाषाओं के लिए कुछ जानकारी है।

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

@nikomatsakis यह शोध करना अच्छा होगा कि विभिन्न भाषाओं के बीच छोटे अंतरों को किसने प्रेरित किया, लेकिन अगर कोई भी उस शोध को करने के लिए कदम नहीं उठाता है और हम वैसे भी आगे बढ़ना चाहते हैं तो मुझे लगता है कि यूएक्स # 31 का बिल्कुल पालन करना (जो मुझे विश्वास है कि हमारा क्या है) वर्तमान कार्यान्वयन करता है) एक अच्छा डिफ़ॉल्ट है।

यह अभी भी एक विस्तृत डिजाइन के साथ RFC प्रक्रिया से गुजरने लायक हो सकता है, भले ही यह वर्तमान कार्यान्वयन से मेल खाता हो। (कौन से वर्णों का उपयोग किया जा सकता है, उन्हें कैसे सामान्यीकृत किया जाता है / तुल्यता के लिए तुलना की जाती है, हम भविष्य के यूनिकोड संस्करणों से कैसे निपटते हैं, आदि) मेरा सुझाव है कि जो कोई भी इस आरएफसी को लिखता है वह कम से कम एक बार UAX 31 ऊपर से नीचे पढ़ता है।

हम पहचानकर्ताओं के लिए एक नया (या, मौजूदा प्रोफाइल में से किसी एक के प्रतिबंधित उपसमुच्चय का उपयोग करके) PRECIS प्रोफ़ाइल [1] बनाने पर भी विचार कर सकते हैं। यह हमें उन पहचानकर्ताओं को सामान्य बनाने की अनुमति देगा, जिन्हें समान माना जाना चाहिए, भले ही वे थोड़े अलग हों (उदाहरण के लिए, उन स्थानों के लिए जिनमें कीबोर्ड होते हैं, जो आउटपुट टेक्स्ट जो समान दिखता है, लेकिन इसके यूनिकोड प्रतिनिधित्व में थोड़ा भिन्न होता है) और साथ ही एक स्पष्ट प्रदान करता है और नियमों का संक्षिप्त सेट यह निर्धारित करने के लिए कि एक वैध जंग पहचानकर्ता क्या है।

मुझे PRECIS ढांचे के किसी भी मौजूदा जंग कार्यान्वयन के बारे में पता नहीं है (मुझे लगता है कि एक बनाने के लिए आवश्यक बहुत सारे यूनिकोड बुनियादी ढांचे अभी भी गायब हैं, लेकिन इसे शायद कुछ हद तक तय करना होगा)।

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

[1] [आरएफसी 7564](https://tools.ietf.org/html/rfc7564): PRECIS फ्रेमवर्क: एप्लीकेशन प्रोटोकॉल में अंतर्राष्ट्रीय स्ट्रिंग्स की तैयारी, प्रवर्तन, और तुलना

समान दिखने वाले पात्रों के बारे में अच्छी बात। यहाँ विकिपीडिया है
मुद्दे पर लेख
https://en.wikipedia.org/wiki/Duplicate_characters_in_Unicode

यहां एक लेख है जो बताता है कि डुप्लिकेट वर्ण
एशियाई लिपियाँ अधिकतर एकीकृत हैं:

https://people.w3.org/rishida/scripts/chinese/

04/11/2017 को 09:01 अपराह्न को सैम व्हाइट ने लिखा:
>

हम एक नया (या, अधिक संभावना है, a . का उपयोग करके) बनाने पर भी विचार कर सकते हैं
मौजूदा प्रोफाइल में से एक का प्रतिबंधित सबसेट) PRECIS प्रोफाइल [1]
पहचानकर्ताओं के लिए। यह हमें उन पहचानकर्ताओं को सामान्य बनाने की अनुमति देगा जो
उन्हें समान माना जाना चाहिए, भले ही वे थोड़े भिन्न हों (उदा.
उन स्थानों के लिए जिनके पास कीबोर्ड हैं जो समान दिखने वाले टेक्स्ट को आउटपुट करते हैं,
लेकिन इसके यूनिकोड प्रतिनिधित्व में थोड़ा अलग है) और साथ ही प्रदान करें
एक वैध जंग क्या है यह निर्धारित करने के लिए नियमों का एक स्पष्ट और संक्षिप्त सेट
पहचानकर्ता।

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

[1] आरएफसी 7564 https://tools.ietf.org/html/rfc7564 : प्रेसिस फ्रेमवर्क:
अंतर्राष्ट्रीयकृत स्ट्रिंग्स की तैयारी, प्रवर्तन, और तुलना
अनुप्रयोग प्रोटोकॉल में

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/28979#issuecomment-293367700 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABU7-IMgXefW2yZYyM0tn8qLhpGFw0bSks5ru84GgaJpZM4GM3Lj ।

@SamWhite यूनिकोड के NFC या NFKC पर PRECIS क्यों?

यूनिकोड के NFC या NFKC पर PRECIS क्यों?

टीएल: डीआर - सामान्यीकरण केवल एक कदम है जिसे हम यह निर्धारित करते समय करना चाहते हैं कि कुछ वैध पहचानकर्ता है या नहीं। अन्य ऑपरेशनों को भी करने की आवश्यकता हो सकती है (या नहीं भी)।

@SimonSapin यूनिकोड सामान्यीकरण एक PRECIS प्रोफ़ाइल का सिर्फ एक चरण है (इसलिए हम वास्तव में सामान्यीकरण का उपयोग कर रहे होंगे; शायद NFC एक अनुमान पर), हालाँकि, PRECIS अधिक विस्तृत श्रृंखला को कवर करता है। उदाहरण के लिए, सामान्यीकरण फॉर्म चौड़ाई मैपिंग नहीं करते हैं (मुझे नहीं लगता?), इसलिए FullWidth समान पहचानकर्ता नहीं होगा ＦｕｌｌＷｉｄｔｈ । यदि आप एक ऐसे कीबोर्ड पर हैं जो पूर्ण चौड़ाई वाला टेक्स्ट टाइप करना चाहता है तो यह एक समस्या हो सकती है (यह शायद पूर्वी एशियाई वर्णों के साथ लैटिन वर्णों की तुलना में अधिक समस्या है, लेकिन हो सकता है कि पूर्ण चौड़ाई वाले टेक्स्ट का उपयोग करने वाले लोकेल से कोई व्यक्ति हो सकता है झंकार करें और मुझे बताएं कि क्या मैं किसी भी तरह से इस मुद्दे को गलत तरीके से प्रस्तुत कर रहा हूं)। अन्य चीजें जो PRECIS प्रोफ़ाइल कर सकती हैं, उनमें वर्ण गुणों के एक सबसेट को परिभाषित करना शामिल है जिनकी अनुमति है (जैसे अक्षर, संख्याएं, डैश, और एक अक्षर या ऐसा कुछ से शुरू होता है)।

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

आगे पढ़ना: गो स्पेक यही करता है (जो मैंने जो सुझाव दिया है उससे कहीं अधिक सरल है, जो अच्छी बात हो सकती है या नहीं भी हो सकती है): https://golang.org/ref/spec#Source_code_representation

PRECIS क्या उपयोग करता है? क्या कोई प्रोग्रामिंग भाषा है?

PRECIS क्या उपयोग करता है? क्या कोई प्रोग्रामिंग भाषा है?

मुझे यकीन नहीं है कि कोई भी भाषा क्या है लेकिन गो करता है ।

संबंधित गो 2 अंक: गोलंग/गो#16033

मंगलवार, 11 अप्रैल, 2017 को 02:07:49 अपराह्न -0700 बजे, सैम व्हाइट ने लिखा:

उदाहरण के लिए, सामान्यीकरण प्रपत्र चौड़ाई मानचित्रण नहीं करते हैं, इसलिए FullWidth वही पहचानकर्ता नहीं होगा जो ＦｕｌｌＷｉｄｔｈ है।

एनएफकेसी ऐसा करता है:

Python 3.6.0 (default, Jan 16 2017, 12:12:55)
[GCC 6.3.1 20170109] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ＦｕｌｌＷｉｄｔｈ = 1
>>> FullWidth
1

--
सादर,
लिलीजवग

@ सैमवाइट , आपके पहले लिंक में मुझे लगता है:

identifier = letter { letter | unicode_digit } .
letter        = unicode_letter | "_" .

लेकिन जहाँ तक मैं बता सकता हूँ कि गो वर्तमान में कोई सामान्यीकरण नहीं करता है और PRECIS का उपयोग करना एक प्रस्ताव है। क्या वो सही है?

लेकिन जहाँ तक मैं बता सकता हूँ कि गो वर्तमान में कोई सामान्यीकरण नहीं करता है और PRECIS का उपयोग करना एक प्रस्ताव है। क्या वो सही है?

@SimonSapin यह सही है; ठीक है, वास्तव में एक प्रस्ताव भी नहीं, इस मुद्दे के माध्यम से सोचा जाने वाला एक विचार (क्षमा करें, उस वाक्य और मेरे लिंक को दोबारा पढ़ें और यह खराब शब्द था; इसका मतलब यह नहीं था कि यह अभी इसका उपयोग करता है, बस मैं गैर-ASCII पहचानकर्ताओं को संभालने के लिए गो के अलावा वास्तव में कुछ भी नहीं जानता)।

@SimonSapin

यह अभी भी एक विस्तृत डिजाइन के साथ RFC प्रक्रिया से गुजरने लायक हो सकता है, भले ही यह वर्तमान कार्यान्वयन से मेल खाता हो।

मैं

मैं यूएक्स #31 के माध्यम से यह देखने के लिए पढ़ रहा था कि उन्होंने क्या किया, और एक सटीक प्रोफ़ाइल का उपयोग करने का एक और लाभ मेरे सामने खड़ा था: जैसे स्ट्रिंगप्रेप को बहिष्कृत करना और इसके बजाय PRECIS का उपयोग करना, यह यूनिकोड संस्करणों में भविष्य के अनुकूल और चुस्त होने का एक तरीका प्रदान करता है ( व्यक्तिगत कोड बिंदुओं के बजाय कोड बिंदुओं के व्युत्पन्न गुणों पर काम करके)।

जबकि TR31 में इसे संबोधित करने में मदद करने के लिए " अपरिवर्तनीय पहचानकर्ता " की अवधारणा है, यह प्रभावी रूप से फ़्रीफ़ॉर्म वर्ग से प्राप्त PRECIS प्रोटोकॉल का थोड़ा कम प्रतिबंधात्मक संस्करण है, लेकिन बिना किसी विचार के PRECIS ने उस क्रम को दिया है जिसमें नियमों की आवश्यकता होती है। लागू (मुझे नहीं लगता?) यह PRECIS ढांचे द्वारा कवर किए गए किनारे के मामलों को भी कवर नहीं करता है जैसे कि ग्रीक अंतिम सिग्मा का उपयोग, या हंगुल जामो के आसपास के कुछ किनारे के मामले (फिर से, मैं इनमें से किसी में भी विशेषज्ञ नहीं हूं) , लेकिन इसीलिए PRECIS मौजूद है; विशेषज्ञों ने पहले ही काम कर लिया है)।

यह यूनिकोड संस्करणों में भविष्य के अनुकूल और चुस्त होने का एक तरीका प्रदान करता है (व्यक्तिगत कोड बिंदुओं के बजाय कोड बिंदुओं के व्युत्पन्न गुणों पर काम करके)।

मैं इस बिंदु को नहीं समझता। XID_Start और XID_Continue व्युत्पन्न गुण हैं।

मैं इस बिंदु को नहीं समझता। XID_Start और XID_Continue व्युत्पन्न गुण हैं।

मैंने तब UAX 31 को गलत समझा होगा; यह मुझे ऐसा लग रहा था जैसे इसे एक विशिष्ट यूनिकोड संस्करण की आवश्यकता है। फिर से पढ़ना मैं नहीं देख सकता कि मुझे वह कहाँ से मिला है।

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

उदाहरण के लिए, (अपरकेस) बनाम (लोअरकेस) निम्न स्क्रीनशॉट में। लिंटर/गलत/नहीं है, लेकिन यह भी वास्तव में यहां सांप मामले की आवश्यकता को लागू करने के लिए समझ में नहीं आता है।

क्या इमोजी को वेरिएबल नामों में अनुमति देना संभव होगा, भले ही वे स्विफ्ट की तरह XID प्रारंभ/जारी न हों?

@fwrs , इमोजी अब गैर-इमोजी वर्णों की तुलना में अधिक जटिल हैं।

कुछ विक्रेताओं के लिए धन्यवाद, अब आपके पास इमोजी जॉइनिंग (ZWJ) सीक्वेंस हो सकते हैं जो बस अपने रंग और छोटे विवरण बदलते रहते हैं, जिनमें से कई जरूरी नहीं कि नग्न आंखों को दिखाई दें।

साथ ही, इमोजी की परिभाषा हर साल तेजी से विस्तार कर रही है, जो कि सिस्टम-स्तरीय प्रोग्रामिंग भाषा नहीं है जो स्थिर और विश्वसनीय आवश्यकताएं बनना चाहती है।

इसलिए, हालांकि यह प्यारा है, मुझे नहीं लगता कि यह जंग के लक्ष्यों के साथ अच्छी तरह से बैठता है। लेकिन, रस्ट-आधारित स्क्रिप्टिंग/शैक्षिक भाषाओं को उनके लक्ष्यों के आधार पर, इमोजी को अनुमति देने से लाभ हो सकता है।

@ryankurte आपके उदाहरण में एक अर्थ संबंधी समस्या है - आप गणितीय सूत्रों का प्रतिलेखन कर रहे हैं, लेकिन आपने U+2206 वृद्धि के बजाय U+0394 ग्रीक कैपिटल लेटर डेल्टा का उपयोग किया है। पूर्व ग्रीक वर्णमाला का एक अक्षर है, और जैसे कि कैसमैपिंग है; उत्तरार्द्ध एक गणितीय प्रतीक है और नहीं है।

मैं इस टिप्पणी को क्रॉस-लिंक करना चाहता हूं: https://github.com/rust-lang/rust/issues/4928#issuecomment -343137316

मैंने यहां होमोग्लिफ-आधारित हमलों को सक्षम करने की संभावना नहीं देखी है (यदि किसी ने उनका उल्लेख किया है तो कृपया शोर को अनदेखा करें), लेकिन मैंने इस तरह के कोड पर चेतावनी देने वाले एक लिंट का अनुरोध करने के लिए सिर्फ एक क्लिपी समस्या भर दी है:

#![feature(non_ascii_idents)]
fn main() {
    let a = 2;
    let а = 3;
    assert_eq!(a, 2);  // OK
    assert_eq!(а, 3);  // OK
}

संक्षेप में, वे दो a s अलग-अलग यूनिकोड वर्ण हैं, इसलिए दूसरा let बाइंडिंग पहले वाले को छाया नहीं देता है, और दोनों ही पास हो जाते हैं (खेल का मैदान यूनिकोड पहचानकर्ताओं का समर्थन नहीं करता है, हालांकि ऐसा करने का एकमात्र तरीका है कोशिश करें यह स्थानीय रूप से है; मेरे लिए काम करता है)।

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

पुनश्च: यह "सुविधा" गुप्त जंग प्रतियोगिताओं में उपयोगी हो सकती है, हालांकि उस #![feature(non_ascii_idents)] को कुछ भौहें उठानी चाहिए :)

@gnzlbg मेरा मानना ​​​​है कि ग्रीक प्रश्न चिह्नों के लिए लोगों को आपके अर्धविरामों को स्वैप करने से रोकने के लिए भ्रमित करने योग्य पहचान के लिए पहले से ही कुछ समर्थन है, लेकिन मुझे नहीं पता कि यह पहचानकर्ताओं पर लागू होता है या नहीं। अगर ऐसा होता है, तो वह उस समस्या को हल करता है; यदि ऐसा नहीं होता है, तो कम से कम हमारे पास इसे करने के लिए तैयार करने के लिए टूलिंग है।

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

@ केत्सुबन

मेरा मानना ​​​​है कि ग्रीक प्रश्न चिह्नों के लिए लोगों को आपके अर्धविरामों को स्वैप करने से रोकने के लिए भ्रमित करने योग्य पहचान के लिए पहले से ही कुछ समर्थन है, लेकिन मुझे नहीं पता कि यह पहचानकर्ताओं पर लागू होता है या नहीं।

हां, मुझे लगता है कि, जैसा कि क्लिप्पी मुद्दे में @ ओली-ओबीके द्वारा सुझाया गया है, जंग कार्यान्वयन इसके बजाय नवीनतम आधिकारिक भ्रमित सूची का उपयोग करेगा:

http://www.unicode.org/Public/security/revision-06/confusables.txt

समरूपता आधारित हमलों को रोका जा सकता है। हालांकि इस सूची को सिंक में रखने की आवश्यकता होगी, लेकिन यह कुछ ऐसा है जिसे बिल्ड सिस्टम के हिस्से के रूप में स्वचालित किया जा सकता है।

@ केत्सुबन

यदि आप इसके बारे में परवाह करते हैं, तो ऐसी अन्य भाषाएँ हैं जो अपने पहचानकर्ताओं में यूनिकोड का समर्थन करती हैं, और इन भाषाओं में RFC प्रक्रिया के समान प्रक्रियाएँ होती हैं। आप उन्हें चेक करके शुरू कर सकते हैं। कौन जानता है, हो सकता है कि आप इस मुद्दे में प्रतिक्रिया के साथ उन्हें एक साथ मर्ज कर सकें, और आंतरिक फोरम में प्री-आरएफसी प्राप्त कर सकें? उस बिंदु से, यह केवल दूसरों के साथ फीडबैक को शामिल करने/बहस करने के बारे में है, और इससे पहले कि आप इसे जानते हैं आपके पास एक आरएफसी तैयार होगा।

एक तरह से मुझे आशा है कि हम हमेशा के लिए ASCII पहचानकर्ताओं के साथ रहेंगे। यूनिकोड पहचानकर्ताओं को संभालना इतना बड़ा अंतःक्रियाशीलता दर्द है। एनएफकेसी मैपिंग के कुछ और विचित्र उदाहरण यह है कि इस मानचित्र को समान पहचानकर्ता के लिए पसंद किया जाता है:

>>> ℌ = 1
>>> H
1
>>> Ⅸ = 42
>>> IX
42
>>> ℕ = 23
>>> N
23
>>> import math
>>> ℯ = math.e
>>> e
2.718281828459045
>>> ℨ = 2
>>> Z
2

@mitsuhiko असली दुनिया में उस तरह का दर्द होता है। हम इस समस्या को केवल इसलिए नज़रअंदाज़ नहीं कर सकते क्योंकि इससे निपटना कठिन है और इसमें एक ऐसी सुविधा शामिल है जिसका आप _व्यक्तिगत रूप से उपयोग नहीं कर सकते हैं।

साथ ही, वर्तमान आरएफसी स्पष्ट रूप से एनएफकेसी पर एनएफसी का प्रस्ताव करता है, बहुत समान उदाहरणों के बारे में चर्चा के _lot_ के बाद।

https://github.com/rust-lang/rust/issues/55467 के पक्ष में समापन।