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 : firstname.lastname@example.org Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp