Clarify option literalness details #1027
Conversation
| 1. Else: | ||
| 1. If the _option_ value consists of a _literal_: | ||
| 1. Include that information in `rv`. | ||
| 1. Mark `rv` as a literal option value. |
There was a problem hiding this comment.
I like this wording change very much
There was a problem hiding this comment.
This change does seem good.
| 1. Else: | ||
| 1. If the _option_ value consists of a _literal_: | ||
| 1. Include that information in `rv`. | ||
| 1. Mark `rv` as a literal option value. |
There was a problem hiding this comment.
This change does seem good.
spec/formatting.md
Outdated
| To allow for _function handlers_ to ensure that certain _option_ values are set by _literals_, | ||
| the _resolved value_ of each _option_ value MUST include information about | ||
| whether the _option_ value is a _literal_ or a _variable_. | ||
| Note that this information is irrelevant for a _resolved value_ that is not used as the value of an _option_. |
There was a problem hiding this comment.
Hmm. Is it perhaps not clear that "option value" is a syntax feature? This phrase seems to imply that a resolved value could be an option value, and that doesn't really make sense.
We probably ought to explicitly define option value as a term in the Syntax section.
There was a problem hiding this comment.
We probably ought to explicitly define option value as a term in the Syntax section.
Absolutely!
There was a problem hiding this comment.
Let's do that in a separate PR.
|
Does this need to be in 47? It looks 47-ish, as I believe it is non-normative and small. Changing to option value as a term is also a candidate. |
|
Non-normative changes: typos, clarifications, even new definitions, etc we can do; we just need to notify the TC. Normative changes that are important need approval by the TC. |
aphillips
added
fast-track
Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Mark Davis <[email protected]>
4 participants
Fixes #1026