Fix fallback value definition and use #903
Conversation
Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Tim Chevalier <[email protected]>
Co-authored-by: Richard Gibson <[email protected]>
| 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".
There was a problem hiding this comment.
This is a good insight. It means that certain classes of errors will be silent in ICU4C. FWIW, ICU4J probably has similar issues. You can't throw Bad Option without being fatal. Logging the error is about the best one can do.
Co-authored-by: Tim Chevalier <[email protected]>
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. |
…on resolution Co-authored-by: Addison Phillips <[email protected]>
|
@catamorphism I'm ready to merge this, but checking with you before I do, since you previously had a comment. |
|
Seeing no reply, I'm merging this. File issues as needed. |
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.