Skip to content

Address #619: add a note about * variant #666

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 2 commits into from
Feb 20, 2024
Merged

Address #619: add a note about * variant #666

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
89e43f0
Address #619: add a note about `*` variant
aphillips Feb 18, 2024
6b7edd4
Address @stasm's comment
aphillips Feb 19, 2024
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
12 changes: 12 additions & 0 deletions spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -372,6 +372,18 @@ to provide the _pattern_ for the formatting operation.
This is done by ordering and filtering the available _variant_ statements
according to their _key_ values and selecting the first one.

> [!NOTE]
> At least one _variant_ is required to have all of its _keys_ consist of
> the fallback value `*`.
Copy link
Collaborator

@catamorphism catamorphism Feb 19, 2024

Choose a reason for hiding this comment

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

This sentence is a little awkward, but I can't think of a good way to rephrase it.

Unless you do something like:

"An exhaustive variant is required. In an exhaustive variant, every key must be the fallback value *."

Not a big deal, though.

Copy link
Member Author

@aphillips aphillips Feb 20, 2024

Choose a reason for hiding this comment

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

Thanks. The phrasing is a bit chewy. I didn't want to create a new term like "exhaustive variant" just for the note.

> Some _selectors_ might be implemented in a way that this _variant_
> cannot be selected in a _valid_ _message_.
> In other cases, this _variant_ might be unreachable only in certain locales.
Copy link
Collaborator

@stasm stasm Feb 19, 2024

Choose a reason for hiding this comment

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

I'm not sure the note about locales is relevant here? How about:

Suggested change
> In other cases, this _variant_ might be unreachable only in certain locales.
> In other cases, this _variant_ may be interpreted as a valid catch-all variant, rather than a fallback in case of failed selection.

>
> In the Tech Preview, feedback from users and implementers is desired about
> whether to relax the requirement that such a "fallback _variant_" appear in
> every message, versus the potential for a _message_ to fail at runtime
> because no matching _variant_ is available.

The number of _keys_ in each _variant_ MUST equal the number of _selectors_.

Each _key_ corresponds to a _selector_ by its position in the _variant_.
Expand Down