New Issue: Whether/How to add new keywords post-2.0?

Notifications Issues
1

24801, "jeremiah-corrado", "Whether/How to add new keywords post-2.0?", "2024-04-09T19:08:19Z"

Following the 2.0 release, we may want to add some new reserved keywords to the language. Some examples of where this might come up:

However, reserving a new word has the potential to break existing user code if the word is already used as an identifier. This issue asks whether we should be able to add new keywords post-2.0 and what the process should be in order to minimize the impact on users.

Proposals:

  1. warning approach:
    When a new keyword is needed to add/improve a language feature, we would implement a compiler warning that lasts for some number of release cycles (maybe 2). The warning would be emitted any time a code uses the word as an identifier, indicating that it will no longer be legal to do so in an upcoming release, and that the name of the variable/proc/enum/etc. should be changed.
    After the warning has been in place for a number of releases, we would then introduce the new keyword and the associated feature. At this point, the parser would emit an error if the keyword is used in a syntactically-incorrect manner.

  2. opt-in approach:
    New keywords (and their associated features) would only be accessible under a new compiler flag (e.g., --chapel-3.0). This would allow users to keep using the stable set of chapel 2.0 features for the time being without the need to adjust their codes for breaking changes. Without throwing the flag, new features that rely on additional keywords would simply be unavailable. Throwing the flag would require renaming any identifiers that happen to share names with new keywords added since chapel 2.0.
    We could also consider creating scripts or some other mechanism to help users migrate their codes to use the flag.
    (this is similar to Rust's editions approach to adding new keywords)