Section 6.2.7 of F&O says (about numeric-unary-plus): Semantically, this operation performs no operation. However this behavior is inconsistent with numeric-unary-minus (and all other numeric operators). Specifically, consider the following query: (+xs:int) instance of xs:int According to the specification, this evaluates to true, however would this be better casting the xs:int to an xs:integer? (i.e. should + behave the same as --?)
Personal response: this description of the "backing function" needs to be read in conjunction with B.2 in the XPath language spec, which makes it clear that when the argument in the op: function signature is given as op:numeric-unary-plus($arg as numeric) as numeric should be read as four function signatures, one of which is op:numeric-unary-plus($arg as xs:integer) as xs:integer and therefore the only guarantee if the operand is an xs:int is that the result is an xs:integer. I agree, however, that the spec could be clarified. I seem to recall (but cannot locate) similar comments on fn:abs() which states "If $arg is negative returns -$arg otherwise returns $arg." - its not really clear whether this allows you to return the xs:integer 3 if the supplied argument is the xs:int 3.
Since you mention the four function signatures of numeric functions, do you have an opinion on bug #5459?
>Since you mention the four function signatures of numeric functions, do you have an opinion on bug #5459? My opinions on the static type inferencing rules in the formal semantics are best not repeated here...
On 22 April 2008 the WG asked the editor to propose revised text for op:unary-plus and op:unary-minus that clarifies that type promotion can take place (as is stated in the table showing the type promotion rules in the introductory section of 6.2.) Proposed text is as follows: For op:unary-plus (6.2.7) replace the Summary with: Summary: Backs up the unary "+" operator and returns its operand with the value unchanged: (+ $arg). The returned value is equal to $arg, and is an instance of xs:integer, xs:decimal, xs:double or xs:float depending on the type of $arg. For op:unary-minus (6.2.8) replace the Summary with: Summary: Backs up the unary "-" operator and returns its operand with the sign reversed: (- $arg). The returned value is an instance of xs:integer, xs:decimal, xs:double or xs:float depending on the type of $arg. To the originator: please close this bug if you are content with this resolution.
(In reply to comment #4) > The returned value is an instance of xs:integer, xs:decimal, xs:double or > xs:float depending on the type of $arg. after reading the above, I think this needs to be tightened. Note that xs:int is also an instance of xs:integer. But you want to say that it is indeed only an instance of one of these four types.
Regarding comment #5: no, I disagree. An implementation of a function is always allowed to return a value that is an instance of a subtype of the declared return type if it chooses. That's a general rule, it's nothing specific to these two operators. (I agree there is room for debate about whether we currently say clearly what the general rule is here; but that doesn't belong as part of this bug.) The proposed text is being drafted as erratum E23.