Fix fallback value definition and use #903
Conversation
Co-authored-by: Addison Phillips <addison@unicode.org>
Co-authored-by: Tim Chevalier <tjc@igalia.com>
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
| but it always resolves to some mapping of string identifiers to values. | ||
| The result of _option resolution_ MUST be a (possibly empty) mapping | ||
| of string identifiers to values; | ||
| that is, errors MAY be emitted, but such errors MUST NOT be fatal. |
There was a problem hiding this comment.
This is the first mention I've noticed in the spec of a non-fatal error, i.e. a warning. If Bad Option is sometimes a fatal error and sometimes a warning, it seems like the spec needs some more language to clarify what implementations should do with it. Or if it's meant to always be a warning, maybe https://github.com/unicode-org/message-format-wg/blob/main/spec/errors.md should say something about that?
There was a problem hiding this comment.
On second thought: from the perspective of an implementation can only signal errors or return usable output, but not both, I'm reading this as saying that the implementation can't signal a Bad Option error. Which is fine, since it's a "MAY".
This addresses concerns raised in #903 - define `option resolution` as a term - require that option order is not significant I was tempted to define the term `resolved options`, but held back.
This addresses concerns raised in #903 - define `option resolution` as a term - require that option order is not significant I was tempted to define the term `resolved options`, but held back.
|
Updated, as per today's discussions. The fallback variable name is now the last one, and it may be a local variable name. |
| @@ -259,6 +259,12 @@ The resolution of a _variable_ fails if no value is identified for its _name_. | |||
| If this happens, an _Unresolved Variable_ error is emitted | |||
| and a _fallback value_ is used as the _resolved value_ of the _variable_. | |||
| If the _resolved value_ identified for the _variable_ _name_ is a _fallback value_, | |||
| a _fallback value_ is used as the _resolved value_ of the _variable_. | |||
There was a problem hiding this comment.
A general issue: The resolved value is logically {datatype, optionMap}. So whenever we have a statement like this, that implies that a fallback value is a resolved value. That means we must say what the optionMap is: I presume an empty map, but we need to be clear.
I think for this case, we can probably put this in one place, the definition of fallback value. We should check other instances of 'resolved value' for completeness.
There was a problem hiding this comment.
Good point. I've updated the text to make the references more explicit. PTAL?
There was a problem hiding this comment.
Excellent fixes to all the fallback value text, thanks!
This is a continuation for the changes of #728, defining a fallback value explicitly as a resolved value, and rephrasing the parts of the spec that refer to resolution failures to instead test for whether a resolved value is a fallback value.