An overview of structural pattern matching for Python

Right now, Rust's approach lets them smoothly add a keyword in the medium term. This is how Rust added, for example, async.

Suppose Rust decided it must have a "new" keyword. Rust 2024 edition could reserve this keyword, and people writing Rust 2024 would be obliged to write r#new when they meant the identifier named "new" while all existing code still compiles. They could then (any time after Rust 2024 "ships") use the reserved keyword for whatever purpose they had in mind in Rust 2024. Since lots of things in Rust are named new e.g. Vec::new() is a very common function call, and would need to be re-written Vec::r#new() this is awkward but it would work.

However, if things were more urgent, say the "new" feature was so critical that otherwise conservative languages like C all rush to provide it, and Rust must do likewise, raw identifiers aren't enough. As I understand it, the intent in that case is to ship an entire feature to provide this capability, named raw keywords. k#new would be the (awkwardly spelled) new keyword immediately, and then Rust 2024 would bless the actual name "new" for it and do all the tidying up in a few years.

The entire namespace where "raw keywords" could live is reserved, so like __Bool in C this is merely awkward spelling. If anything the biggest problem is picking opportunities to use it.