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