Pre-RFC: Raw keywords complementing raw identifiers

language design
1

Summary

Allow keywords to be written as k#keyword, complementing the way raw identifiers can be written as r#identifier.

Motivation

Features that need new keywords cannot be used in existing editions, for example async cannot be used in the 2015 edition. Raw keywords would allow k#async to be used in the 2015 edition without breaking compatibility.

Another use would be to have custom keywords inside macros while allowing macro users to use the same word as an identifier. For example

macro_rules! moo {
    (k#baa $ident:ident) => { /* ... */ };
    ($ident:ident) => { /* ... */ };
}
moo!(k#baa baa);
moo!(baa);

Since r# syntax is already stable for identifiers, the k# syntax would not be something completely new, but would complement that syntax.

2

An $:ident will match keywords. So this already works today (where k#for is interpreted as 3 tokens).

macro_rules! moo {
    (k#for $ident:ident) => { println!("1") };
    ($ident:ident) => { println!("2") };
}

fn main() {
    moo!(k#for for);
    moo!(for);
}
1 Like
3

I briefly mentioned the idea of raw keywords at the end of the RFC 2151 alternatives section with a br#keyword syntax. This would work even in the face of @kennytm’s example for the same reason r# works for raw identifiers – br# is currently greedily parsed only as the start of a raw byte string. It can’t stand separately as br and # tokens unless you separate them with whitespace.

1 Like
4

What’s the use-case for staying on old edition, but using features from new edition? Use of newer-edition keywords requires newer-edition compiler anyway, so I don’t think it provides any forward of backward compatibility.

It seems to be a stop-gap that helps people not upgrade their code to a newer edition, but instead keep the code in a quantum superposition of being incompatible with the new edition and using the new edition at the same time.

5 Likes
5

Maybe for Rust 2021 we should make foo#bar never parse as three tokens, so changes here aren’t so constrained…

6

I was considering compatibility from the point of view of not having to update the working codebase, not from the point of view of not having to upgrade the compiler. So yes, it would help people who do not want to touch their existing working components in order to use a new feature in newer components in the same codebase.

I believe that less divergence between editions is better than more divergence, encouraging users to use the newer edition if possible, but not putting pressure on them to do so.

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.