Keywords to reserve for Rust2018 epoch


#21

lifetime


#22

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.


#23

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.


#24

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).


#25

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.


#26

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.


#27

What about the possibility of people creating crates named with potential keywords? For example there is a crate called await.


#28

@leodasvacas Is your concern how to name such crates in an extern or use?


#29

Yes, I suppose that’s where conflict would arise. I guess we could force people to rename them in Cargo.toml.


#30

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.)


#31

fallible or try, from


#32

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”.


#33

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…


#34

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.)


#35

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".


#36

On the topic of macros being defined with a keyword, what’s the rationale on it not being macro m {(...) => (...)}?


#37

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.