Reserving more keywords

I see a lot of language design proposal, both here and as rfcs...

and almost all of them repurpose existing keywords instead of introducing new ones.

this is one of the main reasons editions exist.

this could possibly be mitigated by having the next edition immediately available on nightly.

Reusing keywords/syntax is bad for discoverabilty. This is how you get the mess that is C++, where f(x) can mean at least 3 different things.

4 Likes

We can absolutely add new keywords in a new edition. But if we do that, people on older editions who want to use the same feature need to use syntax like k#newkeyword. (Which is better than not having the feature at all, but still, it's not ideal.)

We should still do that in any case where a new keyword makes code clearer. We shouldn't reuse existing keywords where they don't fit. But if an existing keyword is clear for a use case, it's worth considering.

Maybe we need something like ${kw} rather than write the keyword directly.

Discussion about keyword makes no sense before we decide whether to accept the new grammar.

Maybe we should regard all the keyword in RFCs as something like ${kw}. Only after the RFC is accepted (and thus lots of people knows the keyword), the discussion of real keyword could be started.

As a (minor, but still illustrative) example: Just recently, someone in the forums was confused by use gaining a new meaning.

Apparently, they had even found the relevant std docs page for keyword use already, but it wasn’t structured in a way that made sufficiently clear – at a glance – that it’s a page describing two completely separate and unrelated language features on the same page.

13 Likes

Two placeholders I've seen used before are k#eyword and . But unfortunately​, syntax is important to the legibility of a feature, and it's rarely as simple as just putting off a single keyword choice.

3 Likes

So, if you use the new feature you need to depend on a new enough rust version for it to exist. And then you might as well also upgrade to the newer edition.

There is the (niche?) use case of optionally enabling support for whatever the keyword is behind a feature flag. But with the new MSRV aware resolver there should be less need to avoid bumping MSRV.

(Also I'm of the opinion that staying on old versions actually hurts you more than it helps, especially for a project with as good compatibility as Rust. And it seems very arbitrary to want to upgrade libraries but use an old compiler. Why not new of both or old of both? Or why not old libraries on a new compiler? Why are people scared of compiler upgrades specifically?)

Syntax is important, thus we need more concern about that, and we need a last effort to rescue a not-so-proper keyword.

For any RFC, we always have 3 questions:

  1. What syntax are we proposed.
  2. Why the syntax is important and how it help users writting Rust programs.
  3. How to implement it / is it worth implement it?

In case the syntax is actually useless, or that syntax is impossible to implement, just discuss about what the syntax is makes no sense. Thus it might be better to focus on the usage and the cost first, as for what the syntax actually is, it might be better to discuss it later.

Only after enough users know how the syntax helps them write Rust programs, will a good-enough syntax be picked out.

I think it's better to have the feature be hard to read on old editions than to make it hard to read and research on all editions.

6 Likes