Rust: Problème de suivi des identifiants non-ASCII (fonction "non_ascii_idents")

/cc @rust-lang/lang

nomination

cc @SimonSapin

Apparemment, nous implémentons ceci : http://www.unicode.org/reports/tr31/ ou quelque chose comme ça.

J'aimerais que cela se stabilise, mais il faudra du travail pour nous persuader que nous faisons ce qu'il faut.

Je n'ai aucune idée de ce qui est juste ici. En plus des recommandations Unicode, nous voudrons peut-être examiner ce que font réellement les autres langages et quels rapports de bogues ou critiques connexes ils reçoivent. Ou était-ce déjà fait lorsque la fonctionnalité a été introduite pour la première fois ?

@SimonSapin
C et C++ utilisent http://unicode.org/reports/tr31/#Alternative_Identifier_Syntax (avec quelques restrictions mineures) et je n'ai vu aucune plainte à ce sujet sur les forums isocpp ou les listes de problèmes :)
Présentation du problème : http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1518.htm
Implémentation dans Clang : http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/UnicodeCharSets.h?view=markup
cc https://github.com/rust-lang/rust/issues/4928

Il y a aussi un problème avec la normalisation des identifiants et le mappage des noms unicode mod aux noms de système de fichiers (sur OS X, IIRC), mais je ne trouve pas le lien pertinent ici : https://github.com /rust-lang/rust/issues/2253. (Dans le pire des cas, les mod s et extern crate s non en ligne peuvent être forcés à être ASCII)

Oui # 2253 est le gros problème que je connais qui me fait m'inquiéter de la stabilisation prématurée des identifiants non Unicode.

(La discussion y est plus large et pourrait sans doute être divisée en deux fils; par exemple, nous _pourrions_ prendre un chemin de normalisation pour les identifiants et un autre pour le contenu littéral de chaîne.)

nous voudrons peut-être migrer cette discussion vers le référentiel RFCS, par exemple à https://github.com/rust-lang/rfcs/issues/802

Je suis d'accord qu'il s'agit d'une fonctionnalité qui mérite d'être soumise au processus RFC.

J'ai réorienté ce problème pour suivre la stabilisation (ou la dépréciation, etc.) de la porte de fonctionnalité non_ascii_idents .

Après discussion lors de la réunion de l'équipe lang, nous avons décidé que oui, un RFC serait la bonne voie à suivre ici. Nous avons besoin de quelque chose qui collecte les solutions d'autres langages, analyse leurs avantages/inconvénients et suggère le choix approprié pour Rust. C'est suffisamment controversé et complexe pour qu'il soit porté à la connaissance de la communauté dans son ensemble - d'autant plus que beaucoup d'entre nous qui piratent quotidiennement Rust n'ont de toute façon pas beaucoup d'expérience avec le non-ASCII.

triage : P-bas

Marquage aussi bas qu'il n'y a pas de RFC à l'heure actuelle et donc pas de contenu exploitable.

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

En JavaScript, Perl 5 et Perl 6, cette fonctionnalité est disponible.
JavaScript (Firefox 50)

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

Perle >=5.12

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

Perl6 (ce n'est pas seulement la prochaine version de Perl. C'est un nouveau langage)

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

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

Je serais heureux de le voir dans Rust aussi.

Pour ce que ça vaut, les identifiants dans ECMAScript 2015 sont basés sur la syntaxe d'identifiant par défaut de l'annexe standard Unicode #31 .

Perl avec use utf8; utilise l'expression rationnelle ci-dessous, avec XID_Start et XID_Continue vraisemblablement aussi de UAX # 31.

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

Oui! Merci @SimonSapin !

Pour Python , c'est <XID_Start> <XID_Continue>* .

Il semble donc que de nombreux langages de programmation qui autorisent les identifiants non ASCII soient basés sur la même norme, mais dans les détails, ils font chacun quelque chose de légèrement différent…

Personnellement, j'aimerais voir la prise en charge des identifiants liés aux mathématiques. Par exemple, ∅ (et les opérateurs d'ensemble, comme ∩ et ∪). Traduire les équations des documents de recherche/spécifications en code est souvent un processus terrible qui se traduit par un code verbeux et difficile à lire. Pouvoir utiliser les mêmes identifiants dans le code que dans les équations mathématiques du papier simplifierait la mise en œuvre et rendrait le code plus facile à vérifier et à comparer aux équations du papier.

Quel est l'intérêt de cette fonctionnalité exactement ? En plus d'ajouter la possibilité de créer un mélange vraiment moche de différentes langues dans votre code (l'anglais est la seule langue véritablement internationale), cela n'apporte aucun avantage à la fonctionnalité de la langue. Ou est-ce le support d'Unicode pour le plaisir de supporter Unicode ?

@DoumanAsh Tous les programmes ne sont pas internationaux et la maîtrise de l'anglais ne doit pas être une exigence pour la programmation.

C'est bien aux mainteneurs de n'importe quel projet de décider que les noms de variables et les commentaires dans leur code doivent être en anglais. C'est ce qui se passe pour de nombreux projets open source, y compris le rustc lui-même. Mais cela ne veut pas dire que le langage doit se limiter à cela.

Le cas d'utilisation que je vois n'est pas pour écrire du code de production, mais pour l'enseignement. Je suis vraiment nul de dire aux gens qu'ils doivent parler couramment l'anglais pour devenir programmeurs. L'autre situation est lorsque vous écrivez une interface utilisateur en langue étrangère, si votre interface utilisateur a une zone de texte intitulée "příjmení" mais que vous finissez par mettre la valeur dans une variable nommée "nom de famille" qui est bizarre. Encore plus étrange si vous avez un champ nommé "rodné_číslo" (numéro d'identification national tchèque). Il n'y a pas de mot anglais analogue pour cela. Donc, si j'écrivais une application fiscale tchèque ou une application bancaire, je devrais utiliser un nom bizarre sans raison valable. Ce n'est pas comme si une telle application serait de toute façon portable dans d'autres langues.

Une autre bonne raison de tenir compte de cela est que les linguistes ont souvent besoin d'utiliser la notation IPA dans les noms de variables. Les noms anglais des symboles IPA peuvent être ridiculement longs. Par exemple, le son anglais américain r dans le mot red est transcrit en un seul caractère ɹ̠ mais est nommé approximant rétroflexif post-alvéolaire. Donc , si j'écris un programme de synthèse vocale, je pourrais raisonnablement vouloir écrire fn say_ɹ̠() au lieu de fn say_post_alveolar_retroflexive_approximant() .

Du côté des choses sans opinion, je pense qu'il y a une discussion intéressante à avoir ici en ce qui concerne les points de code Unicode autorisés à faire partie d'un nom de variable. Par exemple : Puis-je nommer une variable price€ ? Probablement pas, je ne pense pas que price$ fonctionne, n'est-ce pas ? Puis-je créer une macro →![] pour générer des vecteurs ? Je sais que quelqu'un pourrait vouloir le faire, mais → est un "symbole mathématique" http://www.fileformat.info/info/unicode/char/2192/index.htm . Ainsi, lors de la lexification, nous devons décider quels points de code sont acceptables et lesquels ne le sont pas et peut-être que Rust ne devrait pas simplement demander bêtement à la norme unicode si quelque chose est une lettre ou non.

@timthelion dans l'implémentation actuelle Rust ne demande pas simplement à la norme unicode si quelque chose est une lettre ou non - il s'appuie sur les propriétés unicode XID_Start et XID_Continue qui ont un comportement correct et intuitif dans tous vos exemples.

• say_ɹ̠ est autorisé car 'ɹ' et '̠' sont XID_Continue.
• price€ et price$ ne sont pas autorisés car '€' et '$' ne sont pas XID_Continue.
• →![] n'est pas autorisé car '→' n'est pas XID_Start.
• příjmení et rodné_číslo sont autorisés.

@dtolnay merci pour l'explication. J'espère que vous n'avez pas été offensé par mon utilisation du mot « bêtement », c'était peut-être un mot mal choisi.

Non, je souligne simplement que les grands esprits pensent de la même manière et que les braves gens du comité technique Unicode avaient les mêmes préoccupations que vous.

Je peux proposer d'autres cas d'utilisation en production.

Certains mots dans un domaine spécifique sont difficiles à traduire en anglais, mais certains programmes (par exemple, les jeux, les services locaux en ligne vers hors ligne) peuvent être confrontés, par exemple les noms de plats chinois, les noms de héros, les noms de lieux. Les programmeurs travaillant pour des entreprises n'ont pas besoin de connaître les traductions en anglais, mais ils doivent donner leurs noms de variable et de fonction. Ils trouveront des noms étranges s'ils doivent utiliser l'anglais, généralement très difficile à comprendre pour les autres collègues.

À ce stade, je pense qu'il ne fait aucun doute qu'il existe de nombreux cas. Il ne reste plus qu'à régler les détails :

• Quels caractères exactement devraient être autorisés. Par exemple, la ponctuation non ASCII devrait probablement être exclue.
• Quel degré de normalisation doit être effectué : deux identifiants peuvent être représentés avec des points de code différents (différents octets UTF-8 dans les fichiers source) mais être toujours considérés comme équivalents.

Plusieurs autres langues s'accordent sur l'annexe standard Unicode # 31, mais présentent de petites différences dans les détails. Idéalement, nous devrions découvrir ce qui a motivé ces différences afin de décider ce qui est le mieux pour Rust.

https://rosettacode.org/wiki/Unicode_variable_names contient des informations pour de nombreuses langues.

Je suis d'accord avec @SimonSapin - personne ne doute que ce serait utile. Le problème est qu'il n'y a pas de solution standard et que beaucoup d'entre nous (par exemple, moi-même) sommes mal placés pour évaluer les compromis. Ce qu'il nous manque, c'est quelqu'un pour recueillir les contraintes et faire une recommandation, je suppose. Je soupçonne qu'à ce stade, toute décision serait préférable à aucune décision - même si je préférerais certainement suivre un précédent (idéalement, une spécification ou une annexe unicode, mais peut-être aussi une autre langue) que d'adopter simplement un autre ensemble de règles.

@nikomatsakis Ce serait bien de rechercher exactement ce qui a motivé les petites différences entre les différentes langues, mais si personne n'intervient pour faire cette recherche et que nous voulons continuer de toute façon, je pense suivre exactement UAX # 31 (ce qui, je crois, est ce que notre l'implémentation actuelle le fait) est une bonne valeur par défaut.

Il peut toujours être utile de passer par le processus RFC avec une conception détaillée, même si cela correspond à l'implémentation actuelle. (Quels caractères peuvent être utilisés, comment ils sont normalisés / comparés pour l'équivalence, comment nous traitons les futures versions Unicode, etc.) Je suggère à quiconque écrit cette RFC de lire UAX 31 de haut en bas au moins une fois.

Nous pouvons également envisager de créer un nouveau (ou, plus probablement, d'utiliser un sous-ensemble restreint de l'un des profils existants) profil PRECIS [1] pour les identifiants. Cela nous permettrait de normaliser les identifiants qui devraient être considérés comme identiques même s'ils sont légèrement différents (par exemple, pour les paramètres régionaux qui ont des claviers qui produisent du texte qui a la même apparence, mais diffère légèrement dans sa représentation Unicode) ainsi que de fournir un clair et un ensemble concis de règles pour déterminer ce qu'est un identifiant Rust valide.

Je ne suis au courant d'aucune implémentation Rust existante du framework PRECIS (une grande partie de l'infrastructure Unicode requise pour en créer un manque encore, je pense, mais cela devrait probablement être corrigé quelque peu de toute façon).

Je ne me qualifierais pas d'expert, mais j'ai aidé à construire une implémentation de PRECIS et je suis généralement familiarisé avec les RFC et certains des pièges et pièges, donc je serais heureux d'aider (ou de déranger le groupe de travail PRECIS pour obtenir de l'aide) là où c'est nécessaire.

[1] [RFC 7564](https://tools.ietf.org/html/rfc7564) : Cadre PRECIS : Préparation, application et comparaison des chaînes internationalisées dans les protocoles d'application

Bon point sur les personnages qui se ressemblent. Voici le wikipédia
article sur la question
https://en.wikipedia.org/wiki/Duplicate_characters_in_Unicode

Voici un article qui explique que les caractères en double de
les scripts asiatiques sont pour la plupart unifiés :

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

Le 11/04/2017 21h01, Sam Whited a écrit :
>

Nous pouvons également envisager de créer un nouveau (ou, plus probablement, d'utiliser un
sous-ensemble restreint d'un des profils existants) profil PRECIS [1]
pour les identifiants. Cela nous permettrait de normaliser les identifiants qui
doivent être considérés comme identiques même s'ils sont légèrement différents (par ex.
pour les paramètres régionaux qui ont des claviers qui sortent du texte qui se ressemble,
mais diffère légèrement dans sa représentation Unicode) ainsi que fournir
un ensemble de règles clair et concis pour déterminer ce qu'est un Rust valide
identifiant.

Je ne suis au courant d'aucune implémentation Rust existante du PRECIS
framework (une grande partie de l'infrastructure Unicode requise pour créer un
est toujours manquant je pense, mais cela devrait probablement être corrigé
un peu de toute façon).

[1] RFC 7564 https://tools.ietf.org/html/rfc7564 : Framework PRECIS :
Préparation, application et comparaison des chaînes internationalisées
dans les protocoles d'application

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/rust-lang/rust/issues/28979#issuecomment-293367700 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABU7-IMgXefW2yZYyM0tn8qLhpGFw0bSks5ru84GgaJpZM4GM3Lj .

@SamWhited Pourquoi PRECIS sur NFC ou NFKC d'Unicode?

Pourquoi PRECIS plutôt que NFC ou NFKC d'Unicode ?

TL:DR — La normalisation n'est qu'une étape que nous voudrions faire pour déterminer si quelque chose est un identifiant valide. D'autres opérations peuvent (ou non) être également nécessaires.

@SimonSapin La normalisation Unicode n'est qu'une étape d'un profil PRECIS (nous utiliserions donc en fait la normalisation; probablement NFC à deviner), cependant, PRECIS couvre un plus large éventail de choses. Par exemple, les formulaires de normalisation ne font pas de mappage de largeur (je ne pense pas ?), Donc FullWidth ne sera pas le même identifiant que ＦｕｌｌＷｉｄｔｈ . Si vous êtes sur un clavier qui veut taper du texte en pleine largeur, cela peut être un problème (c'est probablement plus un problème avec les caractères d'Asie de l'Est qu'avec les caractères latins, mais peut-être que quelqu'un d'une région qui utilise du texte en pleine largeur pourrait intervenez et dites-moi si je déforme le problème de quelque manière que ce soit). D'autres choses qu'un profil PRECIS peut faire incluent la définition d'un sous-ensemble de propriétés de caractères qui sont autorisées (par exemple, des lettres, des chiffres, des tirets et commence par une lettre ou quelque chose comme ça).

_Avis de non-responsabilité :_ Je n'ai pas vraiment réfléchi à la question de savoir si le mappage du texte en pleine largeur serait souhaitable ou non ; c'est juste un exemple. Il se peut très bien que la normalisation soit tout ce qui compte, ou peut-être que nous ne nous soucions pas du tout de faire une cartographie ; Go ne vérifie que si les identifiants ont la propriété lettre ou chiffre, je pense, donc s'ils se débrouillent avec seulement cela, peut-être que ça nous va aussi. Plus de réflexion est certainement nécessaire.

Lectures complémentaires : c'est ce que fait la spécification Go (ce qui est beaucoup plus simple que ce que j'ai suggéré, ce qui peut être une bonne chose ou non) : https://golang.org/ref/spec#Source_code_representation

Qu'utilise PRECIS ? Est-ce que n'importe quel langage de programmation?

Qu'utilise PRECIS ? Est-ce que n'importe quel langage de programmation?

Je ne suis pas sûr de ce que n'importe quelle langue mais Go fait .

Problème lié à Go 2 : golang/go#16033

Le mar. 11 avril 2017 à 14 h 07 min 49 s -07 h 00, Sam Whited a écrit :

Par exemple, les formulaires de normalisation ne font pas de mappage de largeur, donc FullWidth ne sera pas le même identifiant que ＦｕｌｌＷｉｄｔｈ .

NFKC fait cela :

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

--
Cordialement,
lilydjwg

@SamWhited , dans votre premier lien, je trouve :

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

Mais pour autant que je sache, Go ne fait actuellement aucune normalisation et l'utilisation de PRECIS est une proposition. Est-ce exact?

Mais pour autant que je sache, Go ne fait actuellement aucune normalisation et l'utilisation de PRECIS est une proposition. Est-ce exact?

@SimonSapin c'est exact ; eh bien, même pas vraiment une proposition, juste une idée à réfléchir comme ce problème (désolé, relisez cette phrase et mon lien et il était mal formulé ; je ne voulais pas suggérer qu'il l'utilise en ce moment, juste que je Je ne sais pas ce que fait quoi que ce soit d'autre que Go pour gérer les identifiants non-ASCII).

@SimonSapin

Il peut toujours être utile de passer par le processus RFC avec une conception détaillée, même si cela correspond à l'implémentation actuelle.

👍

J'étais juste en train de lire UAX #31 pour voir ce qu'ils faisaient, et un autre avantage de l'utilisation d'un profil PRECIS m'est apparu : tout comme l'abandon de stringprep et l'utilisation de PRECIS à la place, il offre un moyen d'être compatible et agile à l'avenir entre les versions Unicode ( en agissant sur les propriétés dérivées des points de code au lieu des points de code individuels eux-mêmes).

Bien que TR31 ait un concept d '« identificateurs immuables » pour aider à résoudre ce problème, il s'agit en fait d'une version légèrement moins restrictive d'un protocole PRECIS dérivé de la classe de forme libre, mais sans les considérations que PRECIS a données à l'ordre dans lequel les règles doivent être appliqué (je ne pense pas ?), il ne couvre pas non plus les cas limites couverts par le cadre PRECIS, tels que l'utilisation du sigma final grec, ou certains des cas limites autour de Hangul Jamo (encore une fois, je ne suis pas expert dans l'un ou l'autre de ces , mais c'est pour ça que PRECIS existe, les experts ont déjà fait le travail).

il fournit un moyen d'être compatible et agile à l'avenir entre les versions Unicode (en opérant sur les propriétés dérivées des points de code au lieu des points de code individuels eux-mêmes).

Je ne comprends pas ce point. XID_Start et XID_Continue sont des propriétés dérivées.

Je ne comprends pas ce point. XID_Start et XID_Continue sont des propriétés dérivées.

J'ai peut-être mal compris UAX 31 alors; il me semblait que cela nécessitait une version Unicode spécifique. En relisant, je ne vois pas d'où je tiens ça.

Je ne sais pas si c'est le bon endroit pour poster ceci, mais certains problèmes intéressants sont susceptibles d'apparaître avec le peluchage des symboles mathématiques. Facilement évité en écrivant les noms des variables, mais pourrait être important si une meilleure corrélation avec les équations réelles est un objectif.

Par exemple, Δ (majuscule) contre δ (minuscule) dans la capture d'écran suivante. Le linter n'est pas /faux/, mais cela n'a pas non plus vraiment de sens d'appliquer l'exigence de cas de serpent ici.

serait-il possible d'autoriser les emoji dans les noms de variables même s'ils ne sont pas XID Start/Continue, comme dans Swift ?

@fwrs , les Emojis sont bien plus compliqués maintenant que les personnages non-Emoji.

Grâce à certains fournisseurs, vous pouvez désormais avoir des séquences de jonction Emoji (ZWJ) qui ne cessent de changer leurs couleurs et leurs petits détails, dont beaucoup ne sont pas nécessairement visibles à l'œil nu.

De plus, la définition d'Emoji se développe rapidement, chaque année, ce qui n'est pas quelque chose dont un langage de programmation au niveau du système qui veut être stable et fiable a besoin.

Donc, bien que ce soit mignon, je ne pense pas que cela corresponde bien aux objectifs de Rust. Cependant, les langages de script / éducatifs basés sur la rouille peuvent bénéficier de l'autorisation des Emojis, en fonction de leurs objectifs.

@ryankurte Il y a un problème sémantique dans votre exemple - vous transcrivez des formules mathématiques, mais vous avez utilisé U + 0394 GREEK CAPITAL LETTER DELTA plutôt que U + 2206 INCREMENT. Le premier est une lettre de l'alphabet grec et, en tant que tel, a un mappage de cas ; ce dernier est un symbole mathématique et non.

Je voudrais croiser ce commentaire : https://github.com/rust-lang/rust/issues/4928#issuecomment -343137316

Je n'ai pas vu la possibilité d'activer les attaques basées sur les homoglyphes ici (si quelqu'un les a mentionnées, veuillez ignorer le bruit), mais je viens de remplir un problème clippy pour demander une peluche qui avertit sur un code comme celui-ci :

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

En un mot, ces deux a s sont des caractères Unicode différents, donc la deuxième liaison let ne masque pas la première, et les deux assertions passent (le terrain de jeu ne semble pas prendre en charge les identifiants Unicode, donc la seule façon de essayez ceci est local; fonctionne pour moi).

Cette "fonctionnalité" peut être utilisée pour introduire des exploits dans les programmes Rust qui sont plus difficiles à détecter, en particulier étant donné que les liaisons let occultantes sont considérées comme idiomatiques par Rust par beaucoup, moi y compris.

PS: cette "fonctionnalité" pourrait être utile dans les concours Rust sournois, bien que ce #![feature(non_ascii_idents)] devrait faire sourciller :)

@gnzlbg Je pense qu'il existe déjà un support pour la détection des éléments confus pour empêcher les gens d'échanger vos points-virgules contre des points d'interrogation grecs et autres, mais je ne sais pas si cela s'applique aux identifiants. Si c'est le cas, cela résout ce problème; si ce n'est pas le cas, nous avons au moins l'outillage pour le faire prêt à l'emploi.

Je suis un peu inquiet qu'il s'agisse d'un candidat pour être fermé et que le code soit supprimé du compilateur car il n'a pas eu de mouvement significatif depuis un certain temps et nécessite une RFC. Je me soucie beaucoup du fait que Rust soit une langue du 21e siècle, ce qui signifie Unicode, et que Rust soit convivial pour les programmeurs non anglophones. Ce qui me manque, c'est la capacité d'écrire une RFC.

@Ketsuban

Je crois qu'il existe déjà un certain support pour la détection des éléments confus pour empêcher les gens d'échanger vos points-virgules contre des points d'interrogation grecs et autres, mais je ne sais pas si cela s'applique aux identifiants.

oui, je pense que, comme suggéré par @oli-obk dans le problème clippy, l'implémentation de Rust utiliserait plutôt la dernière liste officielle confus :

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

les attaques basées sur les homoglyphes peuvent être évitées. Cette liste devrait cependant être synchronisée, mais c'est quelque chose qui peut être automatisé dans le cadre du système de construction.

@Ketsuban

Si vous vous souciez de cela, il existe d'autres langages qui prennent en charge l'unicode dans leurs identifiants, et ces langages ont des processus similaires au processus RFC. Vous pouvez commencer par les vérifier. Qui sait, peut-être pourriez-vous simplement les fusionner avec les commentaires de ce numéro et lancer une pré-RFC dans le forum interne ? À partir de ce moment, il s'agit simplement d'incorporer/de discuter des commentaires avec les autres, et avant que vous ne le sachiez, vous aurez un RFC prêt.

D'une certaine manière, j'espère que nous nous en tiendrons aux identifiants ASCII pour toujours. La gestion des identifiants Unicode est une telle douleur d'interopérabilité. Certains des exemples les plus bizarres de mappages NFKC sont que des choses comme celle-ci correspondent au même identifiant :

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

@mitsuhiko Le monde réel a ce genre de douleur. Nous ne pouvons pas simplement ignorer ce problème car il est difficile à gérer et implique une fonctionnalité dont vous n'avez _personnellement_ aucune utilité.

De plus, la RFC actuelle propose explicitement NFC plutôt que NFKC, après de nombreuses discussions sur des exemples très similaires à ceux-ci.

Clôture en faveur de https://github.com/rust-lang/rust/issues/55467.