Repository navigation
Tracking Issue for #![feature(char_is_xid)] #164841
Description
Feature gate: #![feature(char_is_xid)]
This is a tracking issue for methods to check if a character belongs in an identifier as defined by Unicode XID sets.
Public API
// core::char::methods
impl char {
pub fn is_xid_continue(self) -> bool;
pub fn is_xid_start(self) -> bool;
}Steps / History
(Remember to update the S-tracking-* label when checking boxes.)
- ACP: Add Unicode XID related functionalities to
proc_macrocrate libs-team#540 - Implementation: core: implement
char::is_xid_{start|continue}#164474 - Stabilization PR1
Unresolved Questions
- None yet.
Footnotes
Reacted by Trevor Gross
Reacted by teor
Activity
sleepycatcoding commentedon Oct 24, 2026
@rustbot label -S-tracking-unimplemented
sleepycatcoding commentedon Oct 24, 2026
@rustbot label +S-tracking-needs-to-bake
Rollup merge of rust-lang#164844 - sleepycatcoding:char_is_xid_tracki…
Rollup merge of rust-lang#164844 - sleepycatcoding:char_is_xid_tracki…
Rollup merge of rust-lang#164844 - sleepycatcoding:char_is_xid_tracki…
Unrolled build for #164844 in rollup 164865
fmease commentedon Oct 25, 2026
It's obviously the plan to eventually use
char::is_xid_{start,continue}in rustc, right? This would mean every timechar::is_xid_*s' or ratherstd's Unicode version got upgraded, T-lang would need to FCP it unless T-lang started delegating that decision (CC #148321 (comment) whose status I don't know). Just something of note.In any case, this can't really be (fully) done today since
rustc_lexerhas to compile on stable (at least under cfgnot(feature = "nightly")) since it's used by rust-analyzer which must compile on stable.Moreover,
char::is_xid_*on nightly probably followschar::UNICODE_VERSIONwhich is Unicode 18.0.0 at the time of writing. However, the Unicode standard used for Rust, the language, is currently Unicode 17.0.0.hanna-kruppe commentedon Oct 25, 2026
Good point. I guess we could technically keep the standard library's unicode version separate from the the unicode version used for Rust syntax. Coupling them is required to fully achieve the ACP's original motivation of matching Rust identifier syntax, but keeping them separate is no worse (in practice likely better) than the current practice of everyone depending on third party libraries and occasionally bumping that dependency. But yes, it would be nicer if we could eventually remove this distinction.
For comparison, the Java spec does not specify the exact Unicode version used for its lexical syntax and instead delegates to its standard library.
Jules-Bertholet commentedon Oct 28, 2026
With rust-lang/rfcs#3840, do we want methods for
ID_Compat_Math_Start/ID_Compat_Math_Continue?tgross35 commentedon Oct 28, 2026
I think this could be a reasonable thing for us to do as well. A quick grep for common methods show that we're at least using the Unicode classifiers
is_alphabetic,is_alphanumeric,is_control,is_digit,is_numeric,is_whitespace,split_whitespace, and others in the compiler. Not all are technically user-facing, but many are in some way. It would be significantly easier and better for compiler contributors to adapt the Java approach and say this is okay, also meaning the newis_xid_start/is_xid_continuecan be used, than to need to purge all of these from the compiler and maintain a duplicate set of tables somewhere.Also the crate currently used for identifiers in the compiler isn't part of the rust-lang organization anyway https://docs.rs/unicode-ident/latest/unicode_ident/index.html.
tgross35 commentedon Oct 28, 2026
I think this could be fine to ACP regardless of the RFC. Both those and
is_xid_*can be useful for programming language parsers, and exposing unicode tables is pretty easy (aside fromcoresize).tgross35 commentedon Nov 2, 2026
Regarding the above, rust-lang/reference#2403