Rust: Masalah pelacakan untuk pengidentifikasi non-ASCII (fitur "non_ascii_idents")

/cc @rust-lang/lang

pencalonan

cc @SimonSapin

Rupanya kami menerapkan ini: http://www.unicode.org/reports/tr31/ atau sesuatu seperti itu.

Saya ingin melihat ini stabil, tetapi perlu beberapa upaya untuk meyakinkan diri kita sendiri bahwa kita melakukan hal yang benar.

Saya tidak tahu apa yang benar di sini. Selain rekomendasi Unicode, kami mungkin ingin melihat apa yang sebenarnya dilakukan bahasa lain, dan laporan bug atau kritik terkait apa yang mereka dapatkan. Atau apakah ini sudah dilakukan ketika fitur ini pertama kali diperkenalkan?

@SimonSapin
C dan C++ menggunakan http://unicode.org/reports/tr31/#Alternative_Identifier_Syntax (dengan beberapa batasan kecil) dan saya belum melihat keluhan tentang itu di forum isocpp atau daftar masalah :)
Ikhtisar masalah: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1518.htm
Implementasi di Dentang: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/UnicodeCharSets.h?view=markup
cc https://github.com/rust-lang/rust/issues/4928

Ada juga masalah dengan normalisasi pengidentifikasi dan pemetaan nama unicode mod ke nama sistem file (pada OS X, IIRC), tetapi saya tidak dapat menemukan tautan yang relevan di sini: https://github.com /rust-lang/rust/issues/2253. (Dalam kasus terburuk non-inline mod s dan extern crate s dapat dipaksa menjadi ASCII)

Ya #2253 adalah masalah besar yang saya tahu yang membuat saya khawatir tentang stabilisasi dini pengidentifikasi non-unicode.

(Diskusi di sana lebih luas dan bisa dibilang bisa bercabang menjadi dua utas; misalnya kita _bisa_ mengambil satu jalur normalisasi untuk pengidentifikasi dan satu lagi untuk konten literal string.)

kami mungkin ingin memigrasikan Diskusi ini ke repo RFCS, misalnya di https://github.com/rust-lang/rfcs/issues/802

Saya setuju bahwa ini adalah fitur yang layak untuk dimasukkan melalui proses RFC.

Saya telah menggunakan kembali masalah ini untuk melacak stabilisasi (atau penghentian, dll) dari gerbang fitur non_ascii_idents .

Setelah berdiskusi dalam pertemuan tim lang, kami memutuskan bahwa ya, RFC akan menjadi cara yang tepat untuk maju di sini. Kami membutuhkan sesuatu yang mengumpulkan solusi dari bahasa lain, menganalisis pro/kontra, dan menyarankan pilihan yang tepat untuk Rust. Ini kontroversial dan cukup kompleks sehingga harus dibawa ke komunitas luas -- terutama karena banyak dari kita yang meretas Rust setiap hari tidak memiliki banyak pengalaman dengan non-ASCII.

triase: P-rendah

Menandai serendah tidak ada RFC saat ini dan karenanya tidak ada konten yang dapat ditindaklanjuti.

cc https://github.com/rust-lang/rust/issues/7539

Dalam JavaScript, Perl 5 dan Perl 6 fitur ini tersedia.
JavaScript (Firefox 50)

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

Perl >=5.12

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

Perl6 (ini bukan hanya versi Perl berikutnya. Ini adalah bahasa baru)

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

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

Saya akan senang melihatnya di Rust juga.

Untuk apa nilainya, pengidentifikasi dalam ECMAScript 2015 didasarkan pada Sintaks Pengidentifikasi Default dari Unicode Standard Annex #31 .

Perl dengan use utf8; menggunakan regexp di bawah ini, dengan XID_Start dan XID_Continue mungkin juga dari UAX # 31.

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

Ya! Terima kasih @SimonSapin!

Untuk Python itu <XID_Start> <XID_Continue>* .

Jadi sepertinya banyak bahasa pemrograman yang memungkinkan pengidentifikasi non-ASCII didasarkan pada standar yang sama, tetapi dalam detailnya masing-masing melakukan sesuatu yang sedikit berbeda…

Saya pribadi akan senang melihat dukungan untuk pengidentifikasi terkait matematika. Misalnya, (dan mengatur operator, seperti dan ). Menerjemahkan persamaan dari makalah/spesifikasi penelitian ke dalam kode seringkali merupakan proses yang mengerikan sehingga menghasilkan kode yang bertele-tele dan sulit dibaca. Mampu menggunakan pengidentifikasi yang sama dalam kode yang ada di persamaan matematika makalah akan menyederhanakan implementasi dan akan membuat kode lebih mudah untuk diperiksa dan dibandingkan dengan persamaan makalah.

Apa gunanya fitur ini sebenarnya? Selain menambahkan kemungkinan untuk membuat campuran yang benar-benar jelek dari berbagai bahasa dalam kode Anda (bahasa Inggris adalah satu-satunya bahasa yang benar-benar internasional), itu tidak memberikan manfaat bagi fungsionalitas bahasa. Atau apakah itu mendukung unicode demi mendukung unicode?

@DoumanAsh Tidak setiap program bersifat internasional, dan kefasihan bahasa Inggris tidak harus menjadi persyaratan untuk pemrograman.

Tidak masalah bagi pengelola proyek apa pun untuk memutuskan bahwa nama variabel dan komentar dalam kode mereka harus dalam bahasa Inggris. Inilah yang terjadi pada banyak proyek sumber terbuka, termasuk rustc itu sendiri. Tapi itu tidak berarti bahwa bahasa harus dibatasi untuk itu.

Use case yang saya lihat bukan untuk menulis kode produksi, tapi untuk mengajar. Saya benar-benar payah untuk memberi tahu orang-orang bahwa mereka harus fasih berbahasa Inggris untuk menjadi programmer. Situasi lainnya adalah ketika Anda menulis UI bahasa asing, jika UI Anda memiliki kotak teks berlabel "příjmení" tetapi Anda akhirnya memasukkan nilai dalam variabel bernama "nama belakang" yang aneh. Lebih aneh lagi jika Anda memiliki feild bernama "rodné_číslo" (nomor ID nasional Ceko). Tidak ada kata bahasa Inggris yang analog untuk itu. Jadi, jika saya menulis aplikasi pajak Ceko, atau aplikasi Perbankan, saya harus menggunakan nama yang aneh tanpa alasan yang jelas. Ini tidak seperti aplikasi seperti itu akan portabel ke bahasa lain.

Alasan bagus lainnya untuk memungkinkan hal ini adalah bahwa ahli bahasa sering kali perlu menggunakan notasi IPA dalam nama variabel. Nama-nama bahasa Inggris dari simbol IPA bisa sangat panjang. Misalnya, bunyi r bahasa Inggris Amerika dalam kata merah ditranskripsikan sebagai satu karakter tetapi diberi nama pendekatan retrofleksif pasca-alveolar. https://en.wikipedia.org/wiki/Alveolar_and_postalveolar_approximants Jadi, jika saya menulis program text-to-speach, saya mungkin ingin menulis fn say_ɹ̠() sebagai ganti fn say_post_alveolar_retroflexive_approximant() .

Di sisi non-opini, saya pikir ada diskusi menarik yang bisa dilakukan di sini sehubungan dengan poin kode unicode mana yang diizinkan untuk menjadi bagian dari nama variabel. Misalnya: Dapatkah saya memberi nama variabel price€ ? Mungkin tidak, saya rasa price$ tidak berfungsi bukan? Bisakah saya membuat makro →![] untuk menghasilkan vektor? Saya tahu seseorang mungkin ingin melakukannya, tetapi → adalah "simbol matematika" http://www.fileformat.info/info/unicode/char/2192/index.htm . Jadi ketika lexing, kita perlu membuat keputusan tentang poin kode mana yang dapat diterima dan mana yang tidak dan mungkin karat tidak boleh dengan bodoh menanyakan standar unicode apakah sesuatu itu huruf atau bukan.

@timthelion dalam implementasi saat ini Rust tidak hanya dengan bodoh menanyakan standar unicode apakah sesuatu itu huruf atau bukan - itu bergantung pada properti unicode XID_Start dan XID_Continue yang memiliki perilaku yang benar dan intuitif di semua contoh Anda.

• say_ɹ̠ diperbolehkan karena 'ɹ' dan '̠' keduanya XID_Continue.
• price€ dan price$ tidak diperbolehkan karena '€' dan '$' bukan XID_Continue.
• →![] tidak diperbolehkan karena '→' bukan XID_Start.
• příjmení dan rodné_číslo diperbolehkan.

@dtolnay terima kasih atas penjelasannya. Saya harap Anda tidak tersinggung dengan penggunaan kata "bodoh" saya, mungkin itu adalah kata yang dipilih dengan buruk.

Tidak, hanya menunjukkan bahwa orang-orang hebat berpikiran sama dan orang-orang baik dari komite teknis unicode memiliki kekhawatiran yang sama seperti Anda.

Saya dapat menemukan kasus penggunaan dalam produksi lainnya.

Beberapa kata dalam bidang tertentu sulit untuk diterjemahkan ke dalam bahasa Inggris, tetapi beberapa program (misalnya permainan, layanan lokal online-ke-offline) mungkin harus berurusan dengan, misalnya nama masakan Cina, nama pahlawan, nama tempat. Pemrogram yang bekerja untuk perusahaan tidak perlu tahu apa terjemahan bahasa Inggrisnya, tetapi mereka harus memberikan nama variabel dan fungsi mereka. Mereka akan muncul dengan nama yang aneh jika harus menggunakan bahasa Inggris, biasanya sangat sulit dipahami oleh rekan kerja lainnya.

Pada titik ini saya pikir tidak ada keraguan bahwa ada banyak kasus kami. Yang tersisa untuk dilakukan adalah mencari tahu detailnya:

• Karakter apa yang seharusnya diizinkan. Misalnya tanda baca non-ASCII mungkin harus dikecualikan.
• Berapa banyak normalisasi yang harus dilakukan: dua pengidentifikasi dapat direpresentasikan dengan titik kode yang berbeda (byte UTF-8 berbeda dalam file sumber) tetapi masih dianggap setara.

Beberapa bahasa lain menyetujui Unicode Standard Annex # 31, tetapi memiliki perbedaan kecil dalam detailnya. Idealnya, kami akan mencari tahu apa yang memotivasi perbedaan ini untuk memutuskan apa yang terbaik untuk Rust.

https://rosettacode.org/wiki/Unicode_variable_names memiliki beberapa info untuk banyak bahasa.

Saya setuju dengan @SimonSapin -- tidak ada yang meragukan ini akan berguna. Masalahnya adalah bahwa tidak ada solusi standar dan banyak dari kita (misalnya, saya sendiri) berada dalam posisi yang buruk untuk mengevaluasi pengorbanan. Apa yang kita lewatkan adalah seseorang untuk mengumpulkan batasan dan membuat rekomendasi, saya kira. Saya menduga pada titik ini keputusan apa pun akan lebih disukai daripada tidak ada keputusan -- meskipun saya pasti lebih suka mengikuti beberapa preseden (idealnya, spesifikasi atau lampiran unicode, tetapi mungkin juga bahasa lain) daripada hanya mengadopsi Serangkaian aturan lain.

@nikomatsakis Akan menyenangkan untuk meneliti dengan tepat apa yang memotivasi perbedaan kecil antara berbagai bahasa, tetapi jika tidak ada yang melangkah untuk melakukan penelitian itu dan kami tetap ingin melanjutkan maka saya pikir mengikuti UAX # 31 persis (yang saya yakini adalah apa yang kami implementasi saat ini tidak) adalah default yang bagus.

Mungkin masih layak untuk melalui proses RFC dengan desain terperinci, bahkan jika itu cocok dengan implementasi saat ini. (Karakter mana yang dapat digunakan, bagaimana mereka dinormalisasi / dibandingkan untuk kesetaraan, bagaimana kita menangani versi Unicode di masa mendatang, dll.) Saya menyarankan siapa pun yang menulis RFC ini membaca UAX 31 dari atas ke bawah setidaknya sekali.

Kami mungkin juga ingin mempertimbangkan untuk membuat profil PRECIS baru (atau, lebih mungkin, menggunakan subset terbatas dari salah satu profil yang ada) [1] untuk pengidentifikasi. Ini akan memungkinkan kami untuk menormalkan pengidentifikasi yang harus dianggap sama meskipun mereka sedikit berbeda (misalnya untuk lokal yang memiliki keyboard yang menampilkan teks yang terlihat sama, tetapi sedikit berbeda dalam representasi Unicode-nya) serta memberikan gambaran yang jelas dan seperangkat aturan yang ringkas untuk menentukan pengidentifikasi Rust yang valid.

Saya tidak mengetahui adanya implementasi Rust dari kerangka kerja PRECIS (saya pikir banyak infrastruktur Unicode yang diperlukan untuk membuatnya masih hilang, tetapi ini mungkin harus diperbaiki).

Saya tidak akan menyebut diri saya seorang ahli, tetapi saya telah membantu membangun satu implementasi PRECIS dan umumnya akrab dengan RFC dan beberapa perangkap dan gotcha, jadi saya akan dengan senang hati membantu (atau mengganggu kelompok kerja PRECIS untuk mendapatkan bantuan) di mana diperlukan.

[1] [RFC 7564](https://tools.ietf.org/html/rfc7564): Kerangka PRECIS: Persiapan, Penegakan, dan Perbandingan String Internasional dalam Protokol Aplikasi

Poin bagus tentang karakter yang terlihat sama. Ini wikipedianya
artikel tentang masalah ini
https://en.wikipedia.org/wiki/Duplicate_characters_in_Unicode

Berikut adalah artikel yang menjelaskan bahwa karakter duplikat dari
skrip asia sebagian besar bersatu:

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

Pada 04/11/2017 21:01, Sam Whited menulis:
>

Kami juga dapat mempertimbangkan untuk membuat yang baru (atau, lebih mungkin, menggunakan a
subset terbatas dari salah satu profil yang ada) profil PRECIS [1]
untuk pengidentifikasi. Ini akan memungkinkan kami untuk menormalkan pengidentifikasi yang
harus dianggap sama meskipun sedikit berbeda (mis.
untuk lokal yang memiliki keyboard yang menampilkan teks yang terlihat sama,
tetapi sedikit berbeda dalam representasi Unicode-nya) serta menyediakan
seperangkat aturan yang jelas dan ringkas untuk menentukan apa itu Rust yang valid
pengenal.

Saya tidak mengetahui adanya implementasi Rust dari PRECIS
framework (banyak infrastruktur Unicode yang diperlukan untuk membuatnya
masih hilang saya pikir, tapi ini mungkin harus diperbaiki
agak baik cara).

[1] RFC 7564 https://tools.ietf.org/html/rfc7564 : Kerangka PRECIS:
Persiapan, Penegakan, dan Perbandingan String Internasional
dalam Protokol Aplikasi

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/rust-lang/rust/issues/28979#issuecomment-293367700 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABU7-IMgXefW2yZYyM0tn8qLhpGFw0bSks5ru84GgaJpZM4GM3Lj .

@SamWhited Mengapa PRECIS melalui NFC atau NFKC Unicode?

Mengapa PRECIS melalui NFC atau NFKC Unicode?

TL:DR — Normalisasi hanyalah satu langkah yang ingin kami lakukan saat menentukan apakah sesuatu adalah pengenal yang valid. Operasi lain mungkin (atau mungkin tidak) juga perlu dilakukan.

@SimonSapin Normalisasi Unicode hanyalah satu langkah dari profil PRECIS (jadi kami sebenarnya akan menggunakan normalisasi; mungkin NFC di tebak), namun, PRECIS mencakup lebih banyak hal. Misalnya, formulir normalisasi tidak melakukan pemetaan lebar (saya rasa tidak?), jadi FullWidth tidak akan menjadi pengenal yang sama dengan ＦｕｌｌＷｉｄｔｈ . Jika Anda menggunakan keyboard yang ingin mengetik teks lebar penuh, ini mungkin menjadi masalah (ini mungkin lebih merupakan masalah dengan karakter Asia Timur daripada dengan karakter Latin, tapi mungkin seseorang dari lokal yang menggunakan teks lebar penuh bisa bergabunglah dan beri tahu saya jika saya salah mengartikan masalah ini dengan cara apa pun). Hal lain yang dapat dilakukan profil PRECIS termasuk mendefinisikan subset properti karakter yang diizinkan (misalnya huruf, angka, tanda hubung, dan dimulai dengan huruf atau semacamnya).

_Disclaimer:_ Saya belum benar-benar memikirkan apakah pemetaan teks lebar penuh akan diinginkan atau tidak; itu hanya sebuah contoh. Mungkin normalisasi adalah yang terpenting, atau mungkin kita tidak peduli untuk melakukan pemetaan sama sekali; Pergi hanya memeriksa apakah pengidentifikasi memiliki properti huruf atau angka, saya pikir, jadi jika mereka hanya bertahan dengan itu, mungkin tidak apa-apa bagi kita juga. Lebih banyak pemikiran tentu diperlukan.

Bacaan lebih lanjut: inilah yang dilakukan spesifikasi Go (yang jauh lebih sederhana daripada yang saya sarankan, yang mungkin bagus atau tidak): https://golang.org/ref/spec#Source_code_representation

Apa yang menggunakan PRECIS? Apakah ada bahasa pemrograman?

Apa yang menggunakan PRECIS? Apakah ada bahasa pemrograman?

Saya tidak yakin apa bahasa apa pun selain Go .

Masalah Go 2 terkait: golang/go#16033

Pada Selasa, 11 April 2017 pukul 02:07:49PM -0700, Sam Whited menulis:

Misalnya, formulir normalisasi tidak melakukan pemetaan lebar, jadi FullWidth tidak akan menjadi pengenal yang sama dengan ＦｕｌｌＷｉｄｔｈ .

NFKC melakukan itu:

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

--
Salam Hormat,
lilydjwg

@SamWhited , di tautan pertama Anda, saya menemukan:

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

Tapi sejauh yang saya tahu Go saat ini tidak melakukan normalisasi dan menggunakan PRECIS adalah sebuah proposal. Apakah itu benar?

Tapi sejauh yang saya tahu Go saat ini tidak melakukan normalisasi dan menggunakan PRECIS adalah sebuah proposal. Apakah itu benar?

@SimonSapin itu benar; baik, bahkan bukan proposal, hanya ide untuk dipikirkan seperti masalah ini (maaf, baca ulang kalimat itu dan tautan saya dan kata-katanya buruk; tidak bermaksud menyarankan bahwa itu menggunakannya sekarang, hanya saja saya tidak tahu apa yang sebenarnya dilakukan selain Go untuk menangani pengidentifikasi non-ASCII).

@SimonSapin

Mungkin masih layak untuk melalui proses RFC dengan desain terperinci, bahkan jika itu cocok dengan implementasi saat ini.

👍

Saya baru saja membaca UAX #31 untuk melihat apa yang mereka lakukan, dan manfaat lain menggunakan profil PRECIS menonjol bagi saya: sama seperti menghentikan stringprep dan menggunakan PRECIS sebagai gantinya, ini menyediakan cara untuk menjadi kompatibel dan gesit di masa depan di seluruh versi Unicode ( dengan mengoperasikan properti turunan dari titik kode alih-alih titik kode individual itu sendiri).

Meskipun TR31 memiliki konsep " Identifier yang Tidak Dapat Diubah" untuk membantu mengatasi hal ini, TR31 secara efektif adalah versi protokol PRECIS yang sedikit lebih longgar yang diturunkan dari kelas bentuk bebas, tetapi tanpa pertimbangan yang telah diberikan PRECIS pada urutan aturan yang harus dibuat. diterapkan (saya tidak berpikir?) itu juga tidak mencakup kasus tepi yang dicakup oleh kerangka kerja PRECIS seperti penggunaan sigma akhir Yunani, atau beberapa kasus tepi di sekitar Hangul Jamo (sekali lagi, saya bukan ahli dalam salah satu dari ini , tapi itulah mengapa PRECIS ada; para ahli sudah melakukan pekerjaannya).

ini menyediakan cara untuk menjadi kompatibel dan gesit di masa depan di seluruh versi Unicode (dengan beroperasi pada properti turunan dari poin kode alih-alih poin kode individual itu sendiri).

Saya tidak mengerti poin ini. XID_Start dan XID_Continue adalah properti turunan.

Saya tidak mengerti poin ini. XID_Start dan XID_Continue adalah properti turunan.

Saya mungkin salah memahami UAX 31 saat itu; bagi saya sepertinya diperlukan versi Unicode tertentu. Membaca ulang saya tidak bisa melihat dari mana saya mendapatkannya.

Tidak yakin apakah ini tempat yang tepat untuk memposting ini, tetapi beberapa masalah menarik kemungkinan akan muncul dengan linting simbol matematika. Mudah dihindari dengan menuliskan nama variabel, tetapi bisa menjadi penting jika korelasi yang lebih baik dengan persamaan nyata adalah tujuannya.

Misalnya, (huruf besar) vs. (huruf kecil) di tangkapan layar berikut. Linter tidak /salah/, tetapi juga tidak masuk akal untuk menerapkan persyaratan kasus ular di sini.

apakah mungkin untuk mengizinkan emoji dalam nama variabel meskipun mereka bukan XID Mulai/Lanjutkan, seperti di Swift?

@fwrs , Emoji sekarang jauh lebih rumit daripada karakter non-Emoji.

Berkat beberapa vendor, sekarang Anda dapat memiliki urutan Emoji bergabung (ZWJ) yang terus berubah warna dan detail kecilnya, banyak di antaranya tidak selalu terlihat dengan mata telanjang.

Juga, definisi Emoji berkembang pesat, setiap tahun, yang bukan merupakan bahasa pemrograman tingkat sistem yang ingin stabil dan kebutuhan yang dapat diandalkan.

Jadi, meskipun lucu, saya tidak berpikir itu cocok dengan tujuan Rust. Namun, bahasa skrip/pendidikan berbasis karat dapat mengambil manfaat dari mengizinkan Emoji, tergantung pada tujuannya.

@ryankurte Ada masalah semantik dalam contoh Anda—Anda menyalin rumus matematika, tetapi Anda menggunakan U+0394 GREEK CAPITAL LETTER DELTA daripada U+2206 INCREMENT. Yang pertama adalah huruf alfabet Yunani, dan karena itu memiliki pemetaan huruf; yang terakhir adalah simbol matematika dan tidak.

Saya ingin menautkan silang komentar ini: https://github.com/rust-lang/rust/issues/4928#issuecomment -343137316

Saya belum melihat kemungkinan mengaktifkan serangan berbasis homoglyph di sini (Jika seseorang menyebutkannya, harap abaikan kebisingannya), tetapi saya baru saja mengisi masalah clippy untuk meminta lint yang memperingatkan kode seperti ini:

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

Singkatnya, kedua a s itu adalah karakter unicode yang berbeda sehingga pengikatan let kedua tidak membayangi yang pertama, dan keduanya menegaskan lulus (taman bermain tampaknya tidak mendukung pengidentifikasi unicode jadi satu-satunya cara untuk coba ini secara lokal; berfungsi untuk saya).

"Fitur" ini dapat digunakan untuk memperkenalkan eksploit dalam program Rust yang lebih sulit dideteksi, khususnya mengingat bahwa shadowing let binding dianggap Rust idiomatik oleh banyak orang, termasuk saya sendiri.

PS: "fitur" ini mungkin berguna dalam kontes Rust yang curang, meskipun #![feature(non_ascii_idents)] itu seharusnya membuat Anda penasaran :)

@gnzlbg Saya yakin sudah ada beberapa dukungan untuk deteksi confusables untuk menghentikan orang menukar titik koma Anda dengan tanda tanya Yunani dan semacamnya, tetapi saya tidak tahu apakah itu berlaku untuk pengidentifikasi. Jika ya, maka itu memecahkan masalah itu; jika tidak, setidaknya kita memiliki alat untuk melakukannya.

Saya sedikit khawatir bahwa ini adalah kandidat untuk ditutup dan kode dihapus dari kompiler karena tidak memiliki pergerakan yang signifikan untuk sementara waktu dan membutuhkan RFC. Saya cukup peduli tentang Rust sebagai bahasa abad ke-21, yang berarti Unicode, dan tentang Rust yang ramah terhadap programmer yang tidak berbahasa Inggris. Kekurangan saya adalah kemampuan untuk benar-benar menulis RFC.

@Ketsuban

Saya yakin sudah ada beberapa dukungan untuk deteksi confusables untuk menghentikan orang menukar titik koma Anda dengan tanda tanya Yunani dan semacamnya, tetapi saya tidak tahu apakah itu berlaku untuk pengidentifikasi.

ya, saya pikir, seperti yang disarankan oleh @oli-obk dalam masalah clippy, implementasi Rust hanya akan menggunakan daftar resmi terbaru yang membingungkan:

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

serangan berbasis homoglyph dapat dicegah. Daftar ini perlu disinkronkan, tetapi itu adalah sesuatu yang dapat diotomatisasi sebagai bagian dari sistem pembangunan.

@Ketsuban

Jika Anda peduli tentang ini, ada bahasa lain yang mendukung unicode dalam pengidentifikasinya, dan bahasa ini memiliki proses yang mirip dengan proses RFC. Anda bisa mulai dengan memeriksanya. Siapa tahu, mungkin Anda bisa menggabungkannya dengan umpan balik dalam masalah ini, dan memulai pra-RFC di forum internal? Sejak saat itu, ini hanya tentang menggabungkan / memperdebatkan umpan balik dengan orang lain, dan sebelum Anda menyadarinya, Anda akan memiliki RFC yang siap.

Di satu sisi saya berharap kita tetap menggunakan pengidentifikasi ASCII selamanya. Menangani pengidentifikasi unicode adalah masalah interoperabilitas yang sangat besar. Beberapa contoh pemetaan NFKC yang lebih aneh adalah bahwa hal-hal seperti ini memetakan ke pengenal yang sama:

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

@mitsuhiko Dunia nyata memiliki rasa sakit seperti itu. Kami tidak dapat mengabaikan masalah ini begitu saja karena sulit untuk ditangani dan melibatkan fitur yang _secara pribadi_ tidak Anda gunakan.

Juga, RFC saat ini secara eksplisit mengusulkan NFC melalui NFKC, setelah _banyak_ diskusi tentang contoh yang sangat mirip dengan itu.

Menutup mendukung https://github.com/rust-lang/rust/issues/55467.