Keywords to reserve for Rust2018 epoch

[Centril]

This thread is intended to curate a list of keywords we want to reserve in the 2018 epoch. Feel free to propose the inclusion of keywords you think we need (and for what it is needed). This is not necessarily the list we will reserve.

Keywords we (might) want to reserve

Async story

async

await

Error handling

throw, fail

For Err-wrapping

throws

pass, wrap

For Ok-wrapping

catch

catch expressions

General effects

effect

For general effect polymorphism

impure

The inversion of const

panic, nopanic

The panic effect and its inversion

partial, total

The partiality effect and its inversion

trusted

Control flow

is

For EXPR is PAT expressions

Other

dyn

For trait objects and VLAs.

[rpjohnst]

Might also want to reserve catch under error handling? That’s been planned for a while.

[CAD97]

I know dyn is being discussed as a contextual keyword, but it may be worth making a full keyword in the new epoch. It’s also unlikely to be used as an identifier.

[rkruppe]

I assume this is not the right place to debate the pros and cons of reserving any of these suggestions? If so, where will that discussion happen?

[Centril]

Yep, this is just the place to list them so we don’t forget.

Discussion about pros/cons should probably happen where the respective proposals and RFCs are happening… I’ll spend some time linking those RFCs and threads in (but some of these keywords don’t have associated RFCs/threads yet). Perhaps this is not super optimal given that we might want to reserve words we might never end up using… For those words, it is more about giving us the ability to make the choice in the future.

[rkruppe]

Yeah it seems suboptimal. Since each newly reserved keyword has some cost (people not being able to use it as identifier any more), the keywords that are reserved speculatively need a proper discussion too.

[Centril]

Some of these keywords may end up only being contextual so we can mitigate the identifier-problem. Not sure exactly how we should discuss the final list wrt. speculative reservation… ideas? we could just discuss it here or perhaps in one thread for each proposed keyword, but that might be too many threads (or perhaps not, given how important keywords are…)? Perhaps we could discuss them on a related-words basis, so we discuss throw and fail together for example…

[kennytm]

I think existing std functions should never become full keywords. That is, I’d like to remove panic (due to the std::panic module) and is (due to Any::is) from the list.

If the list is about contextual keywords… it doesn’t need a new epoch to introduce non-conflicting contextual keywords (e.g. default, union, auto).

[Centril]

Thanks; I’ll add notes about the drawbacks of those as general keywords soon.

[mark-i-m]

Are there other keywords from popular languages that aren’t already reserved (e.g virtual, and, or, not, auto, friend, operator, try, volatile, class, extends, def, except, with, from, finally, raise, union, data, instance, derive, deriving, instance, macro)?

Also, we may want to reserve any existing contextual keywords.

Also, operators don’t need to be reserved, right?

[ubsan]

Can we also vote to remove keywords? I’d really like access to pure, when dealing with monads. I’d also like fail to be taken off the list, as well as wrap (also for monads). is is a very short keyword - too short, I’ve definitely used it before as the name of a function, and I’d ilke to continue to be able to use it. throw and throws - choose one. Although I’d also prefer raise to throw.

It seems unlikely that Rust will get effects, and so I’m not sure why we’d reserve those keywords. Even if it does, I’d rather have the effects not be built into the compiler… the only one I think is reasonable, even a little, is effect, but we should come up with nicer, non-ascii, syntax.

So basically - remove pure, the effects, is, one of throw/throws, fail.

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