What is the behavior of :number when passed an option with a non-integer value?

[catamorphism]

The spec for the :number function refers to five different options whose values must be a non-negative integer, beginning with minimumIntegerDigits and continuing from there.

However, it's unspecified what the behavior should be when something that can't be coerced to a non-negative integer is passed in for the value of one of these options. (I also assume that "non-negative integer" should include strings that can be parsed as non-negative integers; otherwise, literals as option values wouldn't work.)

If the implementation of the :number function should signal an error, that's a problem because of #738 (there is no error type that really fits this case).

If the error handling is meant to be implementation-dependent, then I think the registry spec should say that.

[aphillips]

I also assume that "non-negative integer" should include strings that can be parsed as non-negative integers; otherwise, literals as option values wouldn't work.

The literal case should be made extremely clear in the spec because it will be the most common.

If the implementation of the :number function should signal an error, that's a problem because of #738 (there is no error type that really fits this case).

The "invalid expression" error is intended, I believe, to cover this. We didn't create a "bad option" sub-type for this error (like we did for operand mismatch), but we could.

If the error handling is meant to be implementation-dependent, then I think the registry spec should say that.

I agree that it should. I think some "bad option values" might be ignored or recoverable, while in other cases it might not be.

"implementation-dependent" might mean several things. It could allow implementations to choose what level of error to emit. Or it could define the level for that specific function/option.