lifetime
1 Like
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:
struct Box<T: ?Sized, existential 'a>(&'a move T);
Other keywords proposed for this purpose include some, any and exists.
1 Like
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.
3 Likes
We should reserve guard to be able to revive the let...else RFC with a less controversial syntax (guard is what is used in Swift AFAIK).
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.
3 Likes
What about the possibility of people creating crates named with potential keywords? For example there is a crate called await.
@leodasvacas Is your concern how to name such crates in an extern or use?
Yes, I suppose that’s where conflict would arise. I guess we could force people to rename them in Cargo.toml.
You’ll be able to use RFC 2151 raw identifiers, something like:
extern crate r#await;
use r#await::Await;
(Raw identifiers are not meant to look pretty – just to make such use possible.)
3 Likes
fallible or try, from
1 Like
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).
And of course macros make everything hard...
Maybe delegate, for New RFC for delegation: anyone interested in contributing??
(Downside: delagate as a noun is used as the term for closure in some languages.)
1 Like
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".
5 Likes
On the topic of macros being defined with a keyword, what’s the rationale on it not being macro m {(...) => (...)}?
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.
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.