Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Clarify option literalness details #1027

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 21, 2025
Merged

Clarify option literalness details #1027

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
42126aa
Clarify option literalness details
gibson042 Feb 20, 2025
3877131
Reword description of option value literalness information
gibson042 Feb 20, 2025
cd79606
Update spec/formatting.md
aphillips Feb 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 13 additions & 4 deletions spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -137,9 +137,17 @@ as well as a flag to indicate whether
its formatted representation requires isolation
from the surrounding text.

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_.
For each _option_ value, the _resolved value_ MUST indicate if the value
was directly set with a _literal_, as opposed to being resolved from a _variable_.
This is to allow _functions handlers_ to require specific _options_ to be set using _literals_.

> For example, the _default functions_ `:number` and `:integer` require that the _option_
> `select` be set with a _literal_ (`plural`, `ordinal`, or `exact`).
> Allowing a _variable_ in this _option_ would produce a _message_ that
> is impossible to translate because the set of _keys_ is tied to the _selector_ chosen.

> [!NOTE]
> Such information is irrelevant for _resolved values_ not used as the value of an _option_.

The form that _resolved values_ take is implementation-dependent,
and different implementations MAY choose to perform different levels of resolution.
Expand Down Expand Up @@ -329,6 +337,7 @@ the following steps are taken:

6. If the call succeeds,
resolve the value of the _expression_ as the result of that function call.
The value MUST NOT be marked as a literal option value.

If the call fails or does not return a valid value,
emit the appropriate _Message Function Error_ for the failure.
Expand Down Expand Up @@ -395,7 +404,7 @@ For each _option_:
1. If supported, emit a _Bad Option_ error.
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this wording change very much

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change does seem good.

1. Set `res[id]` to be `rv`.
1. Return `res`.

Expand Down