Keyword policy permalink

keyword_policy.md

Keyword policy

Upsides of proper keywords (with no availability on old editions)

• Avoid monotonically increasing tech debt
  • In particular, if contextual keywords accumulate over time, their grammatical interactions are going to get continually trickier
• Forward-compatible with introducing contextual keywords on older editions
• Forward-compatible with future uses that can’t be contextual
  • In case we decide 1.5 year hence that we want to do something new with the keyword.
• Arguably can give better error messages
• Cleaner
• Encourage people to shift editions ?

Upsides of contextual keywords

• Less breakage (varies by keyword, often breakage is with crate name)
• More features available on older editions
  • Greater probability of being able to write code in a customary style even when working in an older project
• Less danger of diagnostics telling you to do things that only work on newer editions (for cases like dyn)

The general case

A review here: https://hackmd.io/lu7wxNbRTuO3C0NITUum6Q?both#

The dyn case

The dyn keyword is a special case, since it’s a change to a commonly-used existing construct, and hence has more widespread implications for diagnostics etc.

We may want to special-case it in the policy, e.g. treat it contextually while treating keywords for new constructs as proper keywords

To argue the opposite, because this is new syntax only, and doesn’t allow new functionality, there’s no need to use this on the old edition.

• Minutes
  • aturon:
    • maybe we should take a conservative stance and add contextual keywords to limit breakage, but:
      • this means that we “pile up” grammar debt so to speak
      • maybe lurking interactions around contextual keywords
      • generally cleaner to use a “full keyword”
    • given that we tend to choose keywords that are rare, plus raw identifiers, etc
      • could go to the other extreme and grab everything as proper keywords
      • but:
        • at least for dyn, there’s a lot of reason to try to support that in the old edition
          • error messages will talk about trait objects, do we want to customize those?
            • no, no we don’t
  • middle path:
    • dyn as contextual keyword
    • new features (try, async) go into new edition as proper keywords
  • centril: too many keywords can be a problem
  • aturon: true but since editions come regularly we probably don’t have to reserve things too aggressively
  • scottmcm: at some point if you use same keyword too often (e.g., C++ static) it has a ton of meanings
    • interesting thing about dyn is that I’m less excited about it being contextual because I don’t need it in 2015
    • in contrast, not having try would make 2015 be more annoying to use
      • (Not that I’m proposing that try would be contextual)
  • use dyn::foo
  • scottmcm: there was talk of using it for VLA syntax ([22; dyn x * 3]), what about that?
    • would that require a full keyword?
    • centril: probably not
  • aturon: I think we should optimize for maintenance cost — avoid split grammars
    • hence dyn and union should be contextual
  • Policy restated generally:
    • optimize for maintenance
    • when possible, prefer a “true keyword” in the new edition
      • notably, for new features
    • existing features with contextual keywords, prefer to stay contextual
      • hence dyn
    • special cases:
      • deprecating existing syntax and adding keyword (dyn), prefer to use contextual, so that we can share across editions, and so that people can migrate
        • error messages, etc

Specific keywords

• Unreservations — https://hackmd.io/1-7EjZ74RuicX7Dunw_jiQ#
• Reservations - https://hackmd.io/lu7wxNbRTuO3C0NITUum6Q?both#