Presence of bare word strings makes addition of new keyword in expression position a breaking change

[sholderbach]

Nushell is allowing the user to provide a string in expression positions without quotes (i.e. not command position, e.g. in argument position, inside a list expression etc.)

e.g.

[foo bar baz]

If in the future (post 1.0 stability) we would decide foo should become a keyword you can use to work with expressions and accept it in expression position this would break existing code and possibly existing NUON data.

For existing keywords we have special logic requiring you to quote them in NUON data, behave already differently when executing existing code and perform the necessary quoting for to nuon

Possible mitigations

1. pre-reserve potential keywords that may be used in an expression way. (e.g. use prior art and create a list of potential future keywords that will require you to quote them even before reaching 1.0, examples without giving it much thought typeof, async, lambda, switch,...)
2. commit to never adding keywords that can be used in expression position (some keywords may only ever exist in statement position or special syntax forms e.g. else)
3. if adding a keyword that will be a breaking change (requiring a Major version bump, political decision if we are willing to accept that) restrict its keyword properties on strict grammar form and as long as those requirements are not met treat it as a string, which will limit the breaking potential but also the quality of error messages we can provide and how well syntax highlighting works.

[IanManske]

Expressions in lists and records usually require parentheses anyways, so I'm not sure if adding new keywords would break your example.

For example, these examples are currently interpreted as lists of bare words (or expressions):

[not false]

[if true {1} else {0}]

The argument position should also be able to be handled by the parser. The command position, on the other hand, I think could be an issue.

[sholderbach]

Good point @IanManske that our current parse_list_expression is already more restrictive.
Any attempts to relax those semantics to allow additional expressivity (or avoid parens) will also have to conclude pre-1.0.

We should at least think about other places where (math) expressions are currently used to verify those restrictions.

false in your example still is a keyword, so before 1.0 we need to pin down the list of literals/sentinel values etc. that could be used like that.

For the command call position I opened #12768