Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reserve various useful future keywords #10293

Closed
nikomatsakis opened this issue Nov 5, 2013 · 16 comments
Closed

reserve various useful future keywords #10293

nikomatsakis opened this issue Nov 5, 2013 · 16 comments
Labels
A-parser Area: The parsing of Rust source code to an AST

Comments

@nikomatsakis
Copy link
Contributor

I think we should reserve some keywords that we don't have specific uses for but which seem like they would generally be handy:

  • where
  • my
  • our
  • their
  • not sure what else
  • imm for immutable/immutably/etc (pnkfelix, 2013nov07)

Nominating.

cc @pnkfelix

@nikomatsakis
Copy link
Contributor Author

Another suggestion: once (is this already reserved?)

@thestinger
Copy link
Contributor

Yeah, once is already considered a real keyword (not just a reserved one).

@nikomatsakis
Copy link
Contributor Author

It occurs to me that proper language versioning might be the right sol'n here. Java has managed to add keywords with (relatively) little pain, for example.

@pnkfelix
Copy link
Member

pnkfelix commented Nov 5, 2013

Language Version markers is issue #3392

@liigo
Copy link
Contributor

liigo commented Nov 6, 2013

+1 for 'where' as a reserved keyword

@pnkfelix
Copy link
Member

pnkfelix commented Nov 7, 2013

Accept that we will decide for 1.0. P-backcompat-lang.

@ghost
Copy link

ghost commented Nov 7, 2013

otherwise like in Haskell.

@huonw
Copy link
Member

huonw commented Nov 7, 2013

@Jurily otherwise is actually just a normal identifier, but is given the value True in the prelude to act as "sugar": http://hackage.haskell.org/package/base-4.6.0.1/docs/src/GHC-Base.html#otherwise

@glaebhoerl
Copy link
Contributor

I did some research looking at other languages' keywords and a list of most common English words for likely candidates.

Generally useful parts of speech (like where and for):

  • from, into, is, of, on, out, to, with

Things Rust doesn't have at the moment but conceivably could, and/or has in the past, and/or which have come up in discussions:

  • class, dynamic, friend, goto, lazy, new, pure, union, volatile

Exception handling:

  • try, catch, finally, throw, throws

Generally useful keywords from other languages which haven't found a home in Rust (and are too long anyways):

  • default, explicit, implicit

Keywords for things Rust has different (better:) solutions, words, and/or syntax for, and is unlikely to ever want, listed only in case someone else thinks differently:

  • alias, auto, begin, case, const, data, def, delegate, delete, end, final, nil, null, object, operator, override, switch, synchronized, then, unless, until, var, void

@thestinger
Copy link
Contributor

I think language versions would be a much better solution than this. It's already getting to the point where very common words are reserved just because. It's annoying enough to need to come up with alternatives to words like loop, but if there are no common words to use at all...

@pnkfelix
Copy link
Member

If we do end up snagging more reserved words (though I agree that proper language versioning would be cleaner), I just wanted to add safe to the mix (as in, the opposite of unsafe).

@bjadamson
Copy link
Contributor

raise

@brson
Copy link
Contributor

brson commented May 13, 2014

I'm also concerned about the future need for safe.

@glaebhoerl
Copy link
Contributor

By the way, with respect to typeof, if we ever add it, couldn't we re-use the existing type keyword instead?

@aturon
Copy link
Member

aturon commented Sep 18, 2014

Nominated. I recall discussing this a couple months ago. Either this should be closed, or it should be on the 1.0 milestone.

@pnkfelix
Copy link
Member

closing; we'll attack each future keyword as it comes up, but just reserving a laundry list is not an idea we want to consider further

flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 10, 2023
…tion, r=dswij

Negate suggestions when needed in `bool_assert_comparison`

changelog: none assuming this gets into the same release as rust-lang#10218

Fixes rust-lang#10291

r? `@dswij`

Thanks to `@black-puppydog` for spotting it early
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The parsing of Rust source code to an AST
Projects
None yet
Development

No branches or pull requests

9 participants