Hi Alain, > On 23 Jan 2015, at 10:02, Alain Williams <a...@phcomp.co.uk> wrote: > >> On Fri, Jan 23, 2015 at 12:24:25AM +0000, Andrea Faulds wrote: >> >> Having it be the same as === would be inconsistent with our existing sorting >> and comparison behaviour, so I don’t think it should be changed. If we made >> it strict like that, we’d also have to define a strict < and > as well, >> otherwise we have a problem, because in some cases ($x !== $y && !($x < $y) >> && !($x > $y)) is TRUE. > > I think that you mentioned that you might come up with another RFC if <=> is > successful - that would be for a <==> operator. > > You might want to mention that ... but it is more complicated if the operands > are of different types - what does it return in that case ? FALSE ? But the > same > as <=> if the types are the same ?
The RFC did originally say that, Davey had thought of it. I'm not too keen on the idea and have removed that bit: I don't really think you can do any reasonable "strict" ordering. An error on unmatching types is a royal pain, and I know this because I've had to deal with Game Maker Language which did this. Sorting by type is fairly unintuitive. I think that if people want strict ordering, it's trivial to implement the particular scheme they want using <=>, casts, type checks, or strcmp(). Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
