👍

I think we should probably take greater pains to explain transitivity. For example, consider

.input {$x :number}
.local $a = {|EUR|}
.local $b = {$a}
{{Balance: {$x :currency currency=$b}.}}

1. Per Literal Resolution, the resolved value of $a is "EUR" (and per the new text in Resolved Values, includes its literal nature).
2. Per Variable Resolution, the resolved value of $b is just the resolved value of $a (i.e., a literal with contents "EUR")—although I cannot determine whether or not implementations are given freedom to drop that propagation by «An implementation MAY perform additional processing when resolving the value of an expression that consists only of a variable».
3. These new steps in Option Resolution don't add literalness to the resolved value of $b, but it's already there so the :currency function will still see it.

In fact, it seems like the new steps here cannot ever have an effect, because the resolved value of a literal option is marked as such in Literal Resolution and the resolved value of a variable referencing another variable is just the resolved value of its target. So rather than changing this algorithm, the PR should instead accompany it with note(s) explaining the above.

However, more normative text is required is for explaining a variant where .local $b = {$a} is replaced by .local $b = {$a :string}, in which it is not currently clear whether or not Function Resolution grants implementations the freedom to return a result that is marked as a literal. I strongly believe that such freedom should not exist, and that literalness be preserved only by direct isolated variable references.

The intent of the changes here is make it so that

{{Balance: {$x :currency currency=EUR}.}}

would have the value of the currency option marked as coming from a literal, while

.local $a = {|EUR|}
{{Balance: {$x :currency currency=$a}.}}

would not.

To make that clearer, maybe the new normative text in Resolved Values needs some work? I'll add a suggestion there.

I agree with @eemeli that what he has is sufficient for now.

The stated problems were where the resolved value of a currency option depended on an input parameter, directly or indirectly. However, requiring detection of that finer-grained information, while possible, seems like a lot of overkill. For the use cases we are concerned about in v47, it is sufficient to enable and allow functions to decline variables, but allow literals.

We can examine later whether we need to refine that further, after 47.

I think the text could be misinterpreted. Is there any reason not to say:

      1. If the _option_ value consists of a _literal_:
         1. Include that information in `rv`.

That works for me.

@gibson042 Would this and the change suggested for line 142 address your concerns?

I think the algorithm also needs an "Else" to strip any "consists of a literal" information from non-literal option values.

I don't see how that's better than encoding the information "this option value consists of a literal".

I think Eemeli's wording is fine.
Moreover, this is something that can be refined after review by the CLDR TC — which is to happen tomorrow. So let's just merge this.

I agree with @eemeli that what he has is sufficient for now.

The stated problems were where the resolved value of a currency option depended on an input parameter, directly or indirectly. However, requiring detection of that finer-grained information, while possible, seems like a lot of overkill. For the use cases we are concerned about in v47, it is sufficient to enable and allow functions to decline variables, but allow literals.

We can examine later whether we need to refine that further, after 47.

I think Eemeli's wording is fine.
Moreover, this is something that can be refined after review by the CLDR TC — which is to happen tomorrow. So let's just merge this.