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 havingtry 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
Upsides of proper keywords (with no availability on old editions)
Upsides of contextual keywords
The general case
The dyn case