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

Skip to content

Replace 'shape' with better terminology #611

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
Jan 21, 2024
Merged

Replace 'shape' with better terminology #611

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5c9715e
Replace 'shape' with better terminology
aphillips Jan 19, 2024
e8c595d
Fix note formatting and make normative ("important")
aphillips Jan 20, 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
46 changes: 22 additions & 24 deletions spec/formatting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,26 +16,28 @@ Formatting of a _message_ is defined by the following operations:
with reference to the current _formatting context_.
This can include multiple steps,
such as looking up the value of a variable and calling formatting functions.
The resolved value is not necessarily in the shape it will finally take,
but is "formattable", i.e. it contains everything required by the eventual formatting.
The form of the resolved value is implementation defined and the
value might not be evaluated or formatted yet.
However, it needs to be "formattable", i.e. it contains everything required
by the eventual formatting.

The resolution of _text_ is rather straighforward,
The resolution of _text_ is rather straightforward,
and is detailed under _literal resolution_.

> **Note**
>
> **This specification does not require either eager or lazy _expression resolution_ of _message_
> parts; do not construe any requirement in this document as requiring either.**
>
> Implementations are not required to evaluate all parts of a _message_ when
> parsing, processing, or formatting.
> In particular, an implementation MAY choose not to evaluate or resolve the
> value of a given _expression_ until it is actually used by a
> selection or formatting process.
> However, when an _expression_ is resolved, it MUST behave as if all preceding
> _declarations_ and _selectors_ affecting _variables_ referenced by that _expression_
> have already been evaluated in the order in which the relevant _declarations_
> and _selectors_ appear in the _message_.
> [!IMPORTANT]
>
> **This specification does not require either eager or lazy _expression resolution_ of _message_
> parts; do not construe any requirement in this document as requiring either.**
>
> Implementations are not required to evaluate all parts of a _message_ when
> parsing, processing, or formatting.
> In particular, an implementation MAY choose not to evaluate or resolve the
> value of a given _expression_ until it is actually used by a
> selection or formatting process.
> However, when an _expression_ is resolved, it MUST behave as if all preceding
> _declarations_ and _selectors_ affecting _variables_ referenced by that _expression_
> have already been evaluated in the order in which the relevant _declarations_
> and _selectors_ appear in the _message_.

- **_Pattern Selection_** determines which of a message's _patterns_ is formatted.
For a message with no _selectors_, this is simple as there is only one _pattern_.
Expand Down Expand Up @@ -101,7 +103,7 @@ In _selectors_, the resolved value of an _expression_ is used for _pattern selec

In a _pattern_, the resolved value of an _expression_ or _markup_ is used in its _formatting_.

The shapes of resolved values are implementation-dependent,
The form that resolved values take is implementation-dependent,
and different implementations MAY choose to perform different levels of resolution.

> For example, the resolved value of the _expression_ `{|0.40| :number style=percent}`
Expand Down Expand Up @@ -219,7 +221,7 @@ the following steps are taken:
- The resolved mapping of _options_.
- If the _expression_ includes an _operand_, its resolved value.

The shapes of the resolved _operand_ and _option_ values are implementation-defined.
The form that resolved _operand_ and _option_ values take is implementation-defined.

An implementation MAY pass additional arguments to the function,
as long as reasonable precautions are taken to keep the function interface
Expand Down Expand Up @@ -412,7 +414,7 @@ First, resolve the values of each _selector_:
1. Append `nomatch` as the last element of the list `res`.
1. Emit a _Selection Error_.

The shape of the resolved values is determined by each implementation,
The form of the resolved values is determined by each implementation,
along with the manner of determining their support for selection.

### Resolve Preferences
Expand Down Expand Up @@ -623,10 +625,6 @@ one {{Category match}}
After _pattern selection_,
each _text_ and _placeholder_ part of the selected _pattern_ is resolved and formatted.

_Formatting_ is a mostly implementation-defined process,
as it depends on the implementation's shape for resolved values
and the result type of the formatting.

Resolved values cannot always be formatted by a given implementation.
When such an error occurs during _formatting_,
an implementation SHOULD emit a _Formatting Error_ and produce a
Expand Down