Change:
Fixes URL
All of the other functions we've defined account for input types that they don't expect, and they return in those cases. We should update to do so as well.
count() has declared type OptionalNodesType for its Argument 1. How would it get anything but that?
includes as a potential value.
Yes. As in Lisp, there is a weird alignment between () and nil... I'm not even sure we need NodesType to have an "Optional" aspect. But if we do, I agree we have to say what count makes out of Nothing (either 0 or Nothing), and shape the return type accordingly.
PR fixes this issue in terms of the current type system in which is represented by a non-empty nodelist and is represented by a( path producing a)n empty nodelist.
My argument for a distinction (related to ). When we first started discussing path expressions (, I think), we decided that was disallowed as a complete expression, e.g. . This was intended to disambiguate from being either an existence test or a check that the value in is (e.g. ). As a result of this decision, the literal was only valid as a ; that is, it can only be used with a comparison operator, and a path such as is syntactically invalid. It also allowed the path to return a node for even though the value that's returned by is . Without this distinction, would return JSON , be evaluated as Test-false, and no node would be returned. This means that there must be some distinction between the result of and the literal , although the colloquial meaning for both is "true." In the interim call, I gave the example that if these are the same, then should be valid. Here's why. If is the same thing as the literal , then I can do substitution and a valid expression should result. Since is a valid expression, it is implied that is a valid expression by substituting back the other way. But the ABNF forbids such an expression, so we have a contradiction, which implies our original assumption (" is the same thing as the literal ") must have been wrong. Pedantically, the literal is just that: a literal. It's no different than the literal . It shouldn't carry any meaning of truthiness behind it, but it is commonly used that way. In terms of our expressions, it should be used as a mere token. is asking if the value in is the JSON token . The comparison returns a "true" or "false" result, an actual boolean value rather than just the JSON token, which can then be interpreted as the final result of the expression, or used as an operand for a logical operator, which itself returns a boolean to be interpreted as the final result of the expression.
I also want to explore the idea of "lowering" a TestBoolean to a JSONBoolean so that it can be used in a comparison. This idea is that we can go from a TestBoolean "true"/"false" to the JSONBoolean /, respectively, but not the other direction. This does retrict the literals and from being used in a logical expression (e.g. ). However, if TestBoolean can be lowered to function as JSONBoolean, then can be lowered to and can be lowered to , still implying that is valid. I think the only recourse here is to keep them distinct ideas.
I agree there should be a clear distinction between JSON booleans and the truth values associated with and . I believe the WG consensus supports this, as does the spec.
Good. Progress. No. The spec does not support this. The spec says that a function which returns can be used in both and . But you just said above that there needs to be a distinction between these. See my response to NAME in URL as to why cannot represent JSON booleans. I don't feel like making that argument again.
(Please also see the discussion in and , which is quite useful to find the root cause of this disagreement.)

Discussion:
integer, that gives the number of nodes in the nodelist.  Note that there is no deduplication of the nodelist. <ins> If the argument is "Nothing" (which corresponds to an empty nodelist), the result is the value "0". </ins> 2.6.5. The "match" function extension provides a way to check whether (the