Description
As described at #1019 (comment) .
.input {$x :number} .local $a = {|EUR|} .local $b = {$a} {{Balance: {$x :currency currency=$b}.}}
- Per Literal Resolution, the resolved value of $a is "EUR" (and per the new [«the resolved value of each option value MUST include information about whether the option value is a literal or a variable.»] text in Resolved Values, includes its literal nature).
- 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».
- These new steps in Option Resolution don't add literalness to the resolved value of $b, but it's already there so the
:currencyfunction 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.