I haven't seen fail/throws/pass/wrap be generally accepted as possible syntaxes beyond cursory mentions. catches had a bit more play and isn't included in this list. This just seems to be throwing darts at a design space that hasn't really been pinned down yet. I'm not sure reserving these words without having a reasonable confidence they'll be used is the right plan, especially given how useful many of them are (pass, fail, wrap).
A keyword for existential quantification. The 'named impl Trait’ RFC proposed ‘existential’, but consensus seems to be that it is too long to become a keyword. Aside from that feature, such a keyword could be re-used to declare existential lifetimes, which would come handy in self-referential types, and perhaps in other places:
What about for new kinds of references? &out, &in, &uninit, &move, &empty, &take, &place are all words I’ve suggested or seen suggested. in and move are already keywords, but the others might be worth considering.
I think in the thread where I had a large discussion on reviving refutable let there was a strong bias towards just using let ... else [match]. guard let ... else [match] does not fix the grammar ambiguity present (see said thread), so the alternative that does not have an ambiguity is unless let ... [match]. I also believe that guard/unless can be contextual in this position, thus my not suggesting either up to this point. guard is also a useful identifier.
Please edit the original post to add links to the RFCs where these keywords are being discussed. I’ve never even heard of half of these being up for reservation.
For any new keyword added, I would really appreciate a compelling reason for “this is exactly why we cannot infer the meaning of this word from the usage”. I do not currently understand why Rust has so many keywords and, without reasons for why they must be, I feel as if some of the current keywords can be un-reserved.
I worry that many things are added to Rust right now because the user base is small(ish) and excited about additions. Without a large corporate user base, it feels as if there are not enough people to say “no”.
Contextual keywords often work decently for items, like union does.
In expressions, though, they're tougher, since so many things have meaning already. like catch { x } could be a struct expression (of type catch, using field initializer short-hand).
Let’s make macro_rules a keyword!
It’s currently a context-sensitive identifier.
Making it a keyword will help to get rid of an illusion that macro_rules! m { (...) => (...) } itself is a macro call + remove some silly special errors like "can’t call a user-defined macro macro_rules".
IIRC, Macros 2.0 are expected to use macro in their definitions. Today's macros got an intentionally-worse syntax as they were always expected to be deprecated eventually.