Rust: 비 ASCII 식별자에 대한 추적 문제(기능 "non_ascii_idents")

/cc @rust-lang/lang

지명

cc @SimonSapin

분명히 우리는 이것을 구현합니다: http://www.unicode.org/reports/tr31/ 또는 이와 유사한 것.

나는 이것이 안정화되기를 바라지만 우리가 옳은 일을 하고 있다고 스스로를 설득하는 데는 약간의 노력이 필요할 것입니다.

여기에 뭐가 맞는지 모르겠다. 유니코드 권장 사항 외에도 다른 언어가 실제로 수행하는 작업과 관련 버그 보고서 또는 비판을 받는지 살펴보고 싶을 수 있습니다. 아니면 이 기능이 처음 도입되었을 때 이미 완료되었습니까?

@SimonSapin
C 및 C++는 http://unicode.org/reports/tr31/#Alternative_Identifier_Syntax (약간의 제한이 있음)를 사용하며 isocpp 포럼이나 문제 목록에서 이에 대한 불만을 본 적이 없습니다. :)
문제 개요: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1518.htm
Clang에서 구현: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/UnicodeCharSets.h?view=markup
참조 https://github.com/rust-lang/rust/issues/4928

식별자의 정규화 및 유니코드 mod 이름을 파일 시스템 이름(OS X, IIRC의 경우)에 매핑하는 데에도 문제가 있지만 여기에서 관련 링크를 찾을 수 없습니다 . https://github.com /rust-lang/rust/issues/2253. (최악의 경우 인라인이 아닌 mod s 및 extern crate s는 강제로 ASCII가 될 수 있음)

예 #2253은 유니코드가 아닌 식별자의 조기 안정화에 대해 걱정하게 만드는 큰 문제입니다.

(여기에 있는 논의는 더 광범위하고 틀림없이 두 개의 스레드로 분기될 수 있습니다. 예를 들어 식별자에 대해 하나의 정규화 경로를 취하고 문자열 리터럴 내용에 대해 다른 하나를 _할 수 있습니다_.)

이 토론을 RFCS 저장소(예: https://github.com/rust-lang/rfcs/issues/802 )로 마이그레이션할 수 있습니다.

나는 이것이 RFC 프로세스를 거쳐야 하는 기능이라는 데 동의합니다.

non_ascii_idents 기능 게이트의 안정화(또는 사용 중단 등)를 추적하기 위해 이 문제의 용도를 변경했습니다.

lang 팀 회의에서 논의한 후 우리는 예, RFC가 여기에서 적절한 방법이 될 것이라고 결정했습니다. 우리는 다른 언어에서 솔루션을 수집하고 장단점을 분석하고 Rust에 적절한 선택을 제안하는 무언가가 필요합니다. 이것은 논쟁의 여지가 있고 충분히 복잡하여 커뮤니티 전체에 가져와야 합니다. 특히 매일 Rust를 해킹하는 많은 사람들이 어쨌든 비 ASCII에 대한 경험이 많지 않기 때문입니다.

분류: P-낮음

현재 RFC가 없으므로 실행 가능한 콘텐츠가 없는 것으로 표시합니다.

참조 https://github.com/rust-lang/rust/issues/7539

JavaScript, Perl 5 및 Perl 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(이것은 Perl의 다음 버전이 아닙니다. 이것은 새로운 언어입니다)

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

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

Rust에서도 볼 수 있어서 기쁩니다.

ECMAScript 2015 의 식별자는 유니코드 표준 부록 #31 의 기본 식별자 구문을 기반으로 합니다.

use utf8; 가 있는 Perl은 아래의 정규 표현식을 사용하며 XID_Start 및 XID_Continue 도 UAX # 31에서 가져온 것 같습니다.

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

네! @SimonSapin 감사합니다!

파이썬 의 경우 <XID_Start> <XID_Continue>* 입니다.

따라서 비 ASCII 식별자를 허용하는 많은 프로그래밍 언어가 동일한 표준을 기반으로 하는 것처럼 보이지만 세부 사항에서 각각은 약간 다른 작업을 수행합니다...

개인적으로 수학 관련 식별자에 대한 지원을 보고 싶습니다. 예를 들어, ∅(그리고 ∩ 및 ∪과 같은 집합 연산자). 연구 논문/사양의 방정식을 코드로 변환하는 것은 종종 장황하고 읽기 어려운 코드를 초래하는 끔찍한 과정입니다. 논문의 수학 방정식에 있는 것과 동일한 식별자를 코드에서 사용할 수 있으면 구현이 단순화되고 코드를 보다 쉽게 ​​확인하고 논문의 방정식과 비교할 수 있습니다.

이 기능의 요점은 정확히 무엇입니까? 코드에서 서로 다른 언어를 정말 보기 흉하게 혼합하여 만들 수 있는 가능성을 추가하는 것 외에(영어가 유일한 진정한 국제 언어임), 언어 기능에 아무런 이점도 주지 않습니다. 아니면 유니코드 지원을 위한 유니코드 지원인가요?

@DoumanAsh 모든 프로그램이 국제적이지는 않으며 영어 유창함이 프로그래밍의 요구 사항일 필요는 없습니다.

코드의 변수 이름과 주석이 영어로 되어 있어야 한다고 결정하는 것은 모든 프로젝트의 훌륭한 관리자입니다. 이것은 Rustc 자체를 포함한 많은 오픈 소스 프로젝트에서 일어나는 일입니다. 그러나 그것이 언어가 그것으로 제한되어야 한다는 것을 의미하지는 않습니다.

내가 본 사용 사례는 프로덕션 코드를 작성하기 위한 것이 아니라 교육을 위한 것입니다. 나는 사람들에게 프로그래머가 되려면 영어에 능통해야 한다고 말하는 것이 정말 짜증납니다. 다른 상황은 외국어 UI를 작성할 때 UI에 "příjmení"라는 텍스트 상자가 있지만 값을 "last name"이라는 변수에 이상한 값을 넣는 경우입니다. 더 이상한 것은 "rodné_číslo"(체코 주민등록번호)라는 필드가 있는 경우입니다. 이와 유사한 영어 단어는 없습니다. 따라서 체코 세금 앱이나 은행 앱을 작성하는 경우 정당한 이유 없이 이상한 이름을 사용해야 했습니다. 그런 앱이 어쨌든 다른 언어로 이식될 수 있는 것과는 다릅니다.

이를 허용하는 또 다른 좋은 이유는 언어학자가 종종 변수 이름에 IPA 표기법을 사용해야 하기 때문입니다. IPA 기호의 영어 이름은 엄청나게 길 수 있습니다. 예를 들어, 빨간색이라는 단어의 미국식 영어 r 소리는 한 문자 ɹ̠로 표기되지만 폐포 후 역굴곡 근사로 명명됩니다. https://en.wikipedia.org/wiki/Alveolar_and_postalveolar_approximants 따라서 텍스트 음성 변환 프로그램을 작성하는 경우 $ fn say_post_alveolar_retroflexive_approximant() 대신 fn say_ɹ̠() 을 작성하는 것이 합리적일 수 있습니다.

의견이 없는 측면에서, 변수 이름의 일부로 허용되는 유니코드 코드 포인트와 관련하여 여기에서 흥미로운 토론이 있다고 생각합니다. 예: 변수 이름을 price€ 로 지정할 수 있습니까? 아마도 아닐 것입니다 price$ 가 작동하지 않는 것 같습니까? 벡터 생성을 위한 →![] 매크로를 생성할 수 있습니까? 누군가가 그렇게하고 싶어 할 수도 있다는 것을 알고 있지만 → "수학 기호" http://www.fileformat.info/info/unicode/char/2192/index.htm 입니다. 따라서 렉싱할 때 어떤 코드 포인트가 허용되고 어떤 코드 포인트가 허용되지 않는지 결정해야 합니다. 그리고 아마도 rust는 무언가가 문자인지 아닌지 유니코드 표준에 멍청하게 묻지 않아야 합니다.

현재 구현에서 @timthelion Rust는 단순히 유니코드 표준에 어떤 것이 문자인지 아닌지 묻지 않습니다. 모든 예제에서 정확하고 직관적인 동작을 하는 XID_Start 및 XID_Continue 유니코드 속성에 의존합니다.

• $# 'ɹ' 및 '̠' 가 모두 XID_Continue이므로 say_ɹ̠ 가 허용됩니다.
• $# '€' 및 '$' 는 XID_Continue가 아니기 때문에 $ price€ 및 price$ 는 허용되지 않습니다.
• $# '→' →![] 는 허용되지 않습니다.
• příjmení 및 rodné_číslo 가 허용됩니다.

@dtolnay 설명 감사합니다. 내가 "멍청하게"라는 단어를 사용한 것에 대해 기분이 상하지 않았으면 좋겠습니다. 아마도 그것은 잘못 선택된 단어였을 것입니다.

아니요, 위대한 사람들이 똑같이 생각하고 유니코드 기술 위원회의 훌륭한 사람들이 당신과 같은 우려를 갖고 있다는 점을 지적한 것입니다.

다른 프로덕션 사용 사례를 생각해낼 수 있습니다.

특정 분야의 일부 단어는 영어로 번역하기 어렵지만 일부 프로그램(예: 게임, 지역 온라인-오프라인 서비스)은 예를 들어 중국 요리 이름, 영웅 이름, 장소 이름을 처리해야 할 수 있습니다. 회사에서 일하는 프로그래머는 영어 번역이 무엇인지 알 필요가 없지만 변수 및 함수 이름을 제공해야 합니다. 그들은 영어를 사용해야 하는 경우 이상한 이름을 떠올릴 것입니다. 일반적으로 다른 동료가 이해하기에는 매우 어렵습니다.

현시점에서 우리 사례가 많다는 것은 의심의 여지가 없다고 생각합니다. 세부 사항을 파악하는 일만 남았습니다.

• 정확히 어떤 문자가 허용되어야 합니다. 예를 들어 ASCII가 아닌 구두점은 제외되어야 합니다.
• 얼마나 많은 정규화를 수행해야 하는지: 두 개의 식별자가 다른 코드 포인트(소스 파일의 다른 UTF-8 바이트)로 표현될 수 있지만 여전히 동등한 것으로 간주됩니다.

다른 여러 언어가 Unicode Standard Annex # 31에 동의하지만 세부 사항에는 약간의 차이가 있습니다. 이상적으로, 우리는 무엇이 Rust에 가장 좋은지 결정하기 위해 무엇이 이러한 차이를 유발하는지 알아낼 것입니다.

https://rosettacode.org/wiki/Unicode_variable_names 에는 여러 언어에 대한 정보가 있습니다.

@SimonSapin 에 동의합니다. 아무도 이것이 유용할 것이라고 의심하지 않습니다. 문제는 표준 솔루션이 없고 우리 중 많은 사람들(예: 나 자신)이 절충안을 평가하는 데 열악한 위치에 있다는 것입니다. 우리가 놓치고 있는 것은 제약 조건을 수집하고 권장 사항을 제시할 사람입니다. 나는 이 시점에서 결정을 내리지 않는 것보다 어떤 결정을 내리는 것이 더 나을 거라고 생각합니다. 그래도 아직 또 다른 규칙 집합을 채택하는 것보다 몇 가지 선례(이상적으로는 유니코드 사양이나 부록이지만 다른 언어일 수도 있음)를 따르는 것을 확실히 선호합니다.

@nikomatsakis 다양한 언어 간의 작은 차이점에 동기를 부여한 정확한 원인을 조사하는 것이 좋겠지만 아무도 그 조사에 나서지 않고 어쨌든 계속 진행하고 싶다면 UAX # 31을 정확히 따르는 것이라고 생각합니다. 현재 구현은) 훌륭한 기본값입니다.

현재 구현과 일치하더라도 세부적인 디자인으로 RFC 프로세스를 진행하는 것이 여전히 가치가 있을 수 있습니다. (어떤 문자를 사용할 수 있는지, 동등성을 위해 정규화/비교하는 방법, 향후 유니코드 버전을 처리하는 방법 등) 이 RFC를 작성하는 사람은 누구든지 UAX 31을 위에서 아래로 한 번 이상 읽을 것을 제안합니다.

또한 식별자에 대해 새 PRECIS 프로필(또는 기존 프로필 중 하나의 제한된 하위 집합을 사용하여) PRECIS 프로필[1]을 만드는 것을 고려할 수도 있습니다. 이렇게 하면 약간 다른 경우에도 동일하게 간주되어야 하는 식별자를 정규화할 수 있을 뿐만 아니라(예: 동일하게 보이지만 유니코드 표현이 약간 다른 텍스트를 출력하는 키보드가 있는 로케일의 경우) 명확한 정보를 제공할 수 있습니다. 유효한 Rust 식별자가 무엇인지 결정하기 위한 간결한 규칙 세트.

저는 PRECIS 프레임워크의 기존 Rust 구현에 대해 알지 못합니다.

스스로를 전문가라고 부르지는 않겠지만 PRECIS 구현 하나를 구축하는 데 도움을 줬고 일반적으로 RFC와 몇 가지 함정과 문제에 익숙합니다. 필요한 곳에.

[1] [RFC 7564](https://tools.ietf.org/html/rfc7564): PRECIS 프레임워크: 응용 프로그램 프로토콜에서 국제화 문자열의 준비, 시행 및 비교

똑같이 생긴 캐릭터에 대한 좋은 점. 여기는 위키피디아
문제에 대한 기사
https://en.wikipedia.org/wiki/Duplicate_characters_in_Unicode

다음은 중복 문자를 설명하는 기사입니다.
아시아 스크립트는 대부분 통합되어 있습니다.

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

2017년 4월 11일 오후 9시 1분에 Sam Whited는 다음과 같이 썼습니다.
>

우리는 또한 새로운(또는 더 가능성이 높은
기존 프로필 중 하나의 제한된 하위 집합) PRECIS 프로필 [1]
식별자의 경우. 이렇게 하면 다음과 같은 식별자를 정규화할 수 있습니다.
약간 다르더라도 동일한 것으로 간주해야 합니다(예:
동일하게 보이는 텍스트를 출력하는 키보드가 있는 로케일의 경우
그러나 유니코드 표현에서 약간 다름) 제공할 뿐만 아니라
유효한 Rust가 무엇인지 결정하기 위한 명확하고 간결한 규칙 세트
식별자.

PRECIS의 기존 Rust 구현에 대해 알지 못합니다.
프레임워크(하나를 만드는 데 필요한 많은 유니코드 인프라
내 생각에는 여전히 누락되었지만 이것은 아마도 수정되어야 할 것입니다
어느 정도).

[1] RFC 7564 https://tools.ietf.org/html/rfc7564 : PRECIS 프레임워크:
국제화 문자열의 준비, 시행 및 비교
응용 프로토콜에서

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28979#issuecomment-293367700 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABU7-IMgXefW2yZYyM0tn8qLhpGFw0bSks5ru84GgaJpZM4GM3Lj .

@SamWhited 유니코드의 NFC 또는 NFKC보다 PRECIS가 필요한 이유는 무엇입니까?

유니코드의 NFC 또는 NFKC보다 PRECIS가 필요한 이유는 무엇입니까?

TL:DR — 정규화는 무언가가 유효한 식별자인지 결정할 때 수행하고자 하는 한 단계일 뿐입니다. 다른 작업도 수행해야 할 수도 있고 수행하지 않을 수도 있습니다.

@SimonSapin 유니코드 정규화는 PRECIS 프로파일의 한 단계일 뿐입니다(그래서 우리는 실제로 정규화를 사용하고 있을 것입니다. 추측에 따르면 NFC일 것입니다). 그러나 PRECIS는 더 광범위한 항목을 다룹니다. 예를 들어, 정규화 형식은 너비 매핑을 수행하지 않으므로(생각하지 않습니까?), 따라서 FullWidth 는 ＦｕｌｌＷｉｄｔｈ 와 동일한 식별자가 아닙니다. 전체 너비 텍스트를 입력하려는 키보드를 사용하는 경우 이것이 문제일 수 있습니다(이는 라틴 문자보다 동아시아 문자에 더 문제가 될 수 있지만 전체 너비 텍스트를 사용하는 로케일의 누군가는 내가 어떤 식으로든 문제를 잘못 표현하고 있는지 알려주세요. PRECIS 프로파일이 할 수 있는 다른 일에는 허용되는 문자 속성의 하위 집합을 정의하는 것이 포함됩니다(예: 문자, 숫자, 대시 및 문자 또는 이와 유사한 것으로 시작).

_면책 조항:_ 저는 실제로 전체 너비 텍스트 매핑이 바람직한지 여부에 대해 생각하지 않았습니다. 그것은 단지 예일 뿐입니다. 정규화가 중요한 전부일 수도 있고 매핑을 전혀 하지 않는 것일 수도 있습니다. Go는 식별자에 문자 또는 숫자 속성이 있는지 확인하기만 하므로, 그것만으로 문제가 해결된다면 우리에게도 괜찮을 것입니다. 확실히 더 많은 생각이 필요합니다.

추가 읽기: 이것은 Go 사양이 하는 일입니다(내가 제안한 것보다 훨씬 간단하며 좋은 것일 수도 있고 아닐 수도 있음): https://golang.org/ref/spec#Source_code_representation

PRECIS는 무엇을 사용합니까? 프로그래밍 언어가 있습니까?

PRECIS는 무엇을 사용합니까? 프로그래밍 언어가 있습니까?

Go 이외의 언어가 무엇인지 잘 모르겠습니다.

관련 Go 2 문제: golang/go#16033

2017년 4월 11일 화요일 02:07:49PM -0700에 Sam Whited는 다음과 같이 썼습니다.

예를 들어, 정규화 형식은 너비 매핑을 수행하지 않으므로 FullWidth 는 ＦｕｌｌＷｉｄｔｈ 와 동일한 식별자가 아닙니다.

NFKC는 다음을 수행합니다.

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

--
친애하는,
lilydjwg

@SamWhited , 첫 번째 링크에서 다음을 찾습니다.

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

그러나 내가 말할 수 있는 한 Go는 현재 정규화를 수행하지 않으며 PRECIS를 사용하는 것이 제안입니다. 그 맞습니까?

그러나 내가 말할 수 있는 한 Go는 현재 정규화를 수행하지 않으며 PRECIS를 사용하는 것이 제안입니다. 그 맞습니까?

@SimonSapin 맞습니다. 글쎄요, 실제로 제안도 아니고 그냥 이 문제처럼 생각해 봐야 할 아이디어입니다(죄송합니다. 그 문장과 제 링크를 다시 읽어보니 잘못된 표현이었습니다. 지금 당장 사용한다는 의미는 아닙니다. 단지 제가 Go 이외의 다른 것은 실제로 비ASCII 식별자를 처리하기 위해 무엇을 하는지 모릅니다).

@SimonSapin

현재 구현과 일치하더라도 세부적인 디자인으로 RFC 프로세스를 진행하는 것이 여전히 가치가 있을 수 있습니다.

👍

방금 UAX #31 을 통해 그들이 한 일을 보고 있었고 PRECIS 프로파일을 사용하는 것의 또 다른 이점이 눈에 띄었습니다. stringprep을 사용하지 않고 대신 PRECIS를 사용하는 것과 마찬가지로 유니코드 버전에서 미래에 호환되고 민첩할 수 있는 방법을 제공합니다( 개별 코드 포인트 자체가 아닌 코드 포인트의 파생 속성에 대해 작동).

TR31에는 이 문제를 해결하는 데 도움이 되는 " Immutable Identifiers "라는 개념 이 있지만 사실상 자유 형식 클래스에서 파생된 PRECIS 프로토콜의 약간 덜 제한적인 버전이지만 PRECIS가 규칙을 지정해야 하는 순서에 대한 고려 사항이 없습니다. 적용 (생각하지 않습니까?) 또한 그리스 최종 시그마 사용과 같은 PRECIS 프레임 워크 또는 한글 자모 주변의 일부 사례를 다루지 않습니다 (다시 말하지만, 나는 이들 중 어느 쪽에도 전문가가 아닙니다. , 그러나 그것이 PRECIS가 존재하는 이유이며 전문가들이 이미 작업을 수행했습니다).

이는 유니코드 버전 전체에서 미래에 호환되고 민첩할 수 있는 방법을 제공합니다(개별 코드 포인트 자체 대신 코드 포인트의 파생 속성에서 작동).

나는 이 점을 이해하지 못한다. XID_Start 및 XID_Continue 는 파생 속성입니다.

나는 이 점을 이해하지 못한다. XID_Start 및 XID_Continue는 파생 속성입니다.

그렇다면 UAX 31을 잘못 이해했을 수 있습니다. 특정 유니코드 버전이 필요한 것처럼 보였습니다. 다시 읽어도 어디서 얻었는지 모르겠습니다.

이것이 이것을 게시하기에 적합한 장소인지 확실하지 않지만, 수학 기호의 보풀과 함께 몇 가지 흥미로운 문제가 나타날 수 있습니다. 변수 이름을 작성하면 쉽게 피할 수 있지만 실제 방정식과의 더 나은 상관 관계가 목표인 경우 중요할 수 있습니다.

예를 들어, 다음 스크린샷에서 Δ(대문자) 대 δ(소문자)입니다. linter는 /wrong/이 아니지만 여기에 스네이크 케이스 요구 사항을 적용하는 것도 이치에 맞지 않습니다.

Swift와 같이 XID 시작/계속이 아니더라도 변수 이름에 이모티콘을 허용할 수 있습니까?

@fwrs , 이모티콘은 이모티콘이 아닌 문자보다 훨씬 더 복잡합니다.

일부 공급업체 덕분에 이제 색상과 작은 세부 사항을 계속 변경하는 Emoji 결합(ZWJ) 시퀀스를 사용할 수 있습니다. 이 중 많은 부분이 반드시 육안으로 볼 수 있는 것은 아닙니다.

또한 Emoji의 정의는 매년 빠르게 확장되고 있습니다. 이는 안정적이고 신뢰할 수 있는 요구 사항을 원하는 시스템 수준 프로그래밍 언어가 아닙니다.

그래서 귀엽긴 하지만 Rust 목표와 잘 어울리지 않는다고 생각합니다. 그러나 녹 기반 스크립팅/교육용 언어는 목표에 따라 Emojis를 허용하는 것이 도움이 될 수 있습니다.

@ryankurte 귀하의 예에는 의미론적 문제가 있습니다. 수학 공식을 기록하고 있지만 U+2206 INCREMENT 대신 U+0394 GREEK CAPITAL LETTER DELTA를 사용했습니다. 전자는 그리스 알파벳 문자이므로 대소문자 매핑이 있습니다. 후자는 수학 기호이며 그렇지 않습니다.

이 의견을 교차 링크하고 싶습니다: 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 은 서로 다른 유니코드 문자이므로 두 번째 let 바인딩은 첫 번째 바인딩을 그림자 처리하지 않으며 두 주장 모두 통과합니다(플레이그라운드는 유니코드 식별자를 지원하지 않는 것 같으므로 유일한 방법은 이것을 로컬에서 시도하십시오; 저에게 효과적입니다).

이 "기능"은 탐지하기 어려운 Rust 프로그램의 익스플로잇을 도입하는 데 사용할 수 있습니다. 특히 섀도잉 let 바인딩이 저를 포함하여 많은 사람들이 관용적 Rust로 간주한다는 점을 감안할 때 그렇습니다.

추신: 이 "기능"은 언더핸드 러스트 콘테스트에서 유용할 수 있습니다. 하지만 #![feature(non_ascii_idents)] 는 약간의 눈살을 찌푸리게 할 것입니다. :)

@gnzlbg 사람들이 세미콜론을 그리스어 물음표로 바꾸는 것을 막기 위해 혼동 감지에 대한 지원이 이미 있다고 생각 하지만 식별자에 적용되는지는 모르겠습니다. 그렇다면 문제가 해결됩니다. 그렇지 않은 경우에는 최소한 이를 수행할 수 있는 도구가 준비되어 있습니다.

한동안 중요한 움직임이 없었고 RFC가 필요하기 때문에 이것이 닫힐 수 있고 코드가 컴파일러에서 제거될 수 있다는 점이 조금 걱정됩니다. 저는 Rust가 유니코드를 의미하는 21세기의 언어이고 Rust가 영어를 사용하지 않는 프로그래머에게 친숙한 것에 대해 상당한 관심을 갖고 있습니다. 내가 부족한 것은 실제로 RFC를 작성하는 능력입니다.

@케츠반

사람들이 세미콜론을 그리스어 물음표로 바꾸는 것을 방지하기 위해 혼동 감지에 대한 지원이 이미 있다고 생각하지만 식별자에 적용되는지 여부는 모르겠습니다.

예, 클리피 문제에서 @oli-obk가 제안한 것처럼 Rust 구현은 대신 최신 공식 혼동 목록을 사용합니다.

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

동형 문자 기반 공격을 방지할 수 있습니다. 이 목록은 동기화 상태로 유지해야 하지만 이는 빌드 시스템의 일부로 자동화할 수 있는 것입니다.

@케츠반

이 점을 염두에 두시면 식별자에 유니코드를 지원하는 다른 언어가 있으며 이러한 언어에는 RFC 프로세스와 유사한 프로세스가 있습니다. 그것들을 확인하는 것으로 시작할 수 있습니다. 이 문제의 피드백과 함께 병합하고 내부 포럼에서 사전 RFC를 얻을 수 있는지 누가 압니까? 그 시점부터 다른 사람들과 피드백을 통합/논쟁하는 것에 관한 것이며, 당신이 그것을 알기도 전에 RFC를 준비하게 될 것입니다.

어떤 면에서 나는 우리가 ASCII 식별자를 영원히 고수하기를 바랍니다. 유니코드 식별자를 처리하는 것은 엄청난 상호 운용성 문제입니다. NFKC 매핑의 더 기이한 예 중 일부는 다음과 같은 항목이 동일한 식별자에 매핑된다는 것입니다.

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

@mitsuhiko 현실 세계는 그런 고통이 있습니다. 다루기 어렵고 _개인적으로_ 사용하지 않는 기능이 포함되어 있기 때문에 이 문제를 무시할 수 없습니다.

또한 현재 RFC는 이와 매우 유사한 예에 대해 _많은_ 논의 후에 NFKC를 통한 NFC를 명시적으로 제안합니다.

https://github.com/rust-lang/rust/issues/55467에 찬성하여 마감합니다.