NogDog A match
might be even more readable, but...
Looking at the manual and the language specification, there is no guarantee that its return values will be limited to {-1, 0, 1}.
I don't know any cases where they aren't, but it's always described as evaluating to an integer that is "less than, equal to, or greater than" zero. The RFC proposing it says it should use {-1, 0, 1}.
Going deeper, it's implemented using the pre-existing comparison infrastructure (turns out PHP already implemented its order comparisons through one function and then picked out which feature of the result to return). That infrastructure returns {-1, 0, 1} for primitive types, but for built-in objects with ordering semantics it defers to those objects' own implementations and just returns what they return. I haven't found any that implement ordering that return anything different, but I didn't check every existing or future extension. Also, as I said, PHP's comparison operators use the same comparison infrastructure and do so without assuming it produces only {-1, 0, 1}, as do functions like usort
that take comparators.
All of which means for safety (or until the language can be more explicit and restrict the operator's behaviour: a move I would endorse) the result should be tested with <0, =0, or >0. Which is silly because, as already noted, that just puts it through exactly the same comparison infrastructure that it just went through. (Not totally silly, as now it's a comparison of integers instead of a comparison of arbitrary values.)