Keywords to reserve for Rust2018 epoch

[ahmedcharles]

Note, it’d be really awesome to have a way to specify raw identifiers. I know there was a proposal for that. Did it ever go anywhere? It’d be nice to get that in before the epoch, so people don’t have to rename their types.

[Ixrec]

It’s in FCP: https://github.com/rust-lang/rfcs/pull/2151

[johnthagen]

Might also be interesting to have a list of the currently unused keywords (like priv?) for comparison. Wouldn’t want to accidentally miss an opportunity to use something that’s already there.

Looks like the list is here.

[est31]

You are aware of Any::is? I don’t think it should be added as a keyword.

[Centril]

@kennytm already noted this =)

[scottmcm]

Might be good to explicitly include a list of “things that won’t be keywords, even if we’d like” (default, union, …) to make it clear that they’re not accidental ommisions.

[glaebhoerl]

Whether a name is already used for something in std seems like a very important consideration for sure, but I’m not sure it needs to be an absolute blocker if, hypothetically, there’s some keyword that we really really want. It doesn’t seem like something that couldn’t be solved with an epoch – duplicate the item with a new name in both epochs (trait methods seem slightly trickier, but worst case you could add default definitions for each in terms of the other), in the old epoch deprecate the old item and the keyword is not available, in the new epoch remove the item and add the keyword. (Again, this is if we have sufficiently strong motivation to do it - it’s obviously a downside.)

[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?.…