It depends on what the semantics of fn:count() are, i.e., is is supposed to do 
the type checks that TreatIterator::nextImpl() does?  If the point of the count 
optimization is not to materialize the objects, then you (obviously) can't do 
type checks.  But is that legal?

However, I think (correct me if I'm wrong) that the presence of fn:count() 
wrapped around an expression changes what the expected type is (to xs:integer) 
and it also makes the quantization checks irrelevant since fn:count() works on 
any length sequence.

If that's true, then TreatIterator::count() would simply call its child's count 
without any other checks.  I think the same would be true for skip().
-- 
https://code.launchpad.net/~zorba-coders/zorba/pub_iter_imp/+merge/201708
Your team Zorba Coders is subscribed to branch lp:zorba.

-- 
Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to