- From: <bugzilla@jessica.w3.org>
- Date: Thu, 16 Apr 2015 09:23:54 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28494 --- Comment #2 from Tim Mills <tim@cbcl.co.uk> --- I hear the sound of a can of worms being opened. Following your explanation, I therefore conclude that declare function local:return($arg) { if (xs:date('2000-01-01') eq current-date()) then () else $arg }; let $x as empty-sequence() := local:return(1) return () should fail with an error, even though the value o4 $x is never used. Here's my reasoning. 1. local:return has static type item()*. Because it depends on the dynamic context, a process can do no better (unless it makes assumptions about the date). 2. let .. return .. is a single expression with two operands, and its static type is empty-sequence(). 3. let $x as empty-sequence() clause is effectively a cardinality check, so any errors resulting from a cardinality-mismatch cannot be optimized away. However, modifying the body to (), let $x as empty-sequence() := local:return(1) return () would be permitted to be optimized away to the empty sequence, because here the concatenation operator is permitted not to evaluate either operand on the basis of their static types. Similarly let $y := let $x as empty-sequence() := local:return(1) return () return $y can also optimize to empty sequence. Another example which shows up this problem is: declare function local:return($arg) { if (xs:date('2000-01-01') eq current-date()) then () else $arg }; declare function local:let($unused as empty-sequence()) as empty-sequence() { () }; local:let(local:return(1)) 1. local:return has static type item()*. Because it depends on the dynamic context, a process can do no better (unless it makes assumptions about the date). 2. local:let is a single expression with one operand, and its static type is empty-sequence(). 3. The function call local:let requires a dynamic check on its argument to check that is has cardinality zero. This can't be optimized away. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 16 April 2015 09:24:00 UTC