Keywords to reserve for Rust2018 epoch

[Centril]

N.B: I’ll spend some time today adding some more details for each keyword and creating a template to follow for new keywords in this thread.

Preliminary template:

mycoolkeyword

• action: one of: reserve, unreserve, nothing
• references: link_to_rfc, link_to_thread, link, …
• contexts: fill in what contexts the keyword will be used… we’ll use this to determine if it should be a full keyword or just contextual
• used as ident in std?: yes or no
• drawbacks: list known cases where you’d like to use this keyword as an identifier
• examples: code_snippet1, code_snippet2, …

[steven099]

throw, fail
For Err-wrapping

throws

pass, wrap
For Ok-wrapping

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

[nielsle]

lifetime

[felix.s]

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.

[canndrew]

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.

[nox]

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

[CAD97]

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.

[bstrie]

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.

[leodasvacas]

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

[mark-i-m]

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

[leodasvacas]

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

[cuviper]

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

[scottmcm]

fallible or try, from

Bikeshed: Rename `catch` blocks to `fallible` blocks

I was contemplating catch blocks again, and musing on the feedback that we shouldn’t use exception terminology since we don’t have exceptions, and the fact that catch blocks in RFC #243 don’t really work like catch blocks in languages like Java anyway (nor like handle in SML). What if we renamed them fallible blocks? For example: type SizeHint = (usize, Option<usize>); pub fn combine(a: SizeHint, b: SizeHint) -> SizeHint { let low = a.0.saturating_add(b.0); let high = fallible { a.1?.…

[twmb]

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

[scottmcm]

“this is exactly why we cannot infer the meaning of this word from the usage”

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…

[scottmcm]

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

[petrochenkov]

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

[IsaacWoods]

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

[scottmcm]

what’s the rationale on it not being macro

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.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.