Allow clamping of digit size options

[aphillips]

Fixes #960

Per the discussion in the 2025-04-14 telecon, allow digit size options to be to clamped to an implementation-specific value.

[sffc]

Does this happen instead of the Bad Option error?

Is there somewhere else in the spec that says what happens if the provided option value is not in-range, whether it is dropped, etc? (Seems like there would be)

[aphillips]

Does this happen instead of the Bad Option error?

No. The spec (on the previous line!) says a Bad Option is emitted, so one is emitted. This proposed addition allows the implementation to do something other than dropping the option on the floor (which would presumably result in the default value for that implementation being used). It also would have an effect on the resolved value of the option.

The spec in general does not define behavior like this because of the layering in the design. What happens in a function is the function's business. Other functions might have similar or different behavior, depending on their needs. (Some options, when in error, leave the function unable to proceed.)

There are two places in the spec where something else could happen (on another layer).

One is during option resolution, but that only results in a map of options to resolved values. That is where the text says that option resolution cannot fail (produce a fatal error). @macchiati and others have proposed allowing function descriptors and to be used to validate values before function resolution. Such evaluation might result in the Bad Option occurring sooner.

The other is during function resolution during formatting. Effectively, "function resolution" is when the function is actually called. The function itself decides whether a Bad Option is a failure or not. If it is a failure, the fallback representation is the result of formatting. Presumably if one clamped the value of a Digit Size Option, one would not emit a fallback representation (there would be no point in clamping the value, since the result is something like {$foo} not a formatted value such as 0.123456789012345678901) making the Bad Option just a non-fatal error.

[sffc]

ok, so maybe a better resolution here is to just say somewhere that when a Bad Option error occurs, implementations may either drop the option value or substitute an implementation-defined replacement?

[eemeli]

To resolve the ambiguity noted by @sffc in #1070 (comment):

Suggested change

	a _Bad Option_ error is emitted.
	If the value exceeds an implementation-defined upper or lower limit,
	the implementation MAY replace it with an implementation-defined value.
	a _Bad Option_ error is emitted and
	the implementation MAY ignore the option value or
	replace it with an implementation-defined value.

[aphillips]

I think it's probably not a good idea to combine a (silently) normative statement and a 2119-keyworded statement in a single sentence. Also, the MAY means "an implementation can ignore the option or replace it or do something else", which is different from what I perceive @sffc is looking for.

I can't suggest here, since the wrong lines are selected, but I'd propose something like:

- If the value of a _digit size option_ does not evaluate as a non-negative integer,
- or if the value exceeds any implementation-defined and option-specific upper or lower limit,
- a _Bad Option_ error is emitted.
+ If the value of a _digit size option_ does not evaluate as a non-negative integer,
+ a _Bad Option_ error is emitted.
+ 
+ If the value of a _digit size option_ exceeds any option-specific 
+ or implementation-defined upper or lower limit,
+ the implementation MUST either ignore the _option_
+ or replace its value with an implementation-defined value.
+ In either case, a _Bad Option_ error is emitted.

(Note that the above changes "exceeds any implementation-defined and option-specific" with or and reverses the order of the two)

[eemeli]

One part of the change that I'm proposing here is allowing an implementation to behave the same way for a digit size option ending up with either -1 or 0 as values for an option that has an implementation-defined minimum of 1. Is there a reason why this should not be allowed?