Thanks for your feedback.
I'll fix the textual errors you mentioned.
- "To compare two numeric strings as numbers, they need to be cast to
floats." This may loose precision for integers. It is better to cast to
numbers (int or float) using, with the canonical way being +$x. But I guess
that won't work under strict_operators. Maybe we should have a (number)
cast (it already exists internally...)
Good point. While in most cases you know if you're working with floats or
integers, adding a way to cast to either an int or float would be nice.
Maybe preferably through a function like
numberval($x) or simply
number($x), so the(type)` syntax is reserved for actual types. That
would be an RFC on its own though.
- This has already been mentioned by others: Having $str1 < $str2 perform
strcmp() style comparison under strict_operators is surprising. I think
that overall the use of lexicographical string comparisons is quite rare
and should be performed using an explicit
strcmp() call. More likely than
not, writing $str1 < $str2 is a bug and should generate a TypeError. Of
course, equality comparisons like $str1 == $str2 should still work, similar
to the distinction you make for arrays.
Ok, fair. I'll change it so <,<=,>,>=,<=> comparison on a string throws a
TypeError, similar to arrays, resources, and objects.
- If I understand correctly, under this RFC "foo" == 0 will throw a
TypeError, but ["foo"] ==  will return false. Generally the behavior of
the recursive comparison here is that it's the same as strict == but all
errors become not-equal instead. Correct? I'm not sure how I feel about
this, as it seems to introduce one more set of semantics next to the weak
==, strict == and === semantics there already are.
The syntax would be
$a == $b (or
$a == ), where $a and $b are a
string/int in one case and both an array in the other case. In the second
case, we can't throw a TypeError as both operands are of the same type.
- I also find it somewhat odd that you can't write something like "$obj !=
null" anymore, only "$obj !== null".
To check against null, it's better to use !==. For objects (and resources)
!= null is ok, but for other types, it's currently not. For
 == null gives true.
- I think the "solution" to the last three points is a) only support
numbers in relational operators (<,<=,>,>=,<=>) and throw TypeErrors
otherwise (maybe modulo provisions for object overloading) and b) allow
comparing any types in == and !=, without throwing a TypeError. The
question "Are 42 and 'foobar' equal?" has a pretty clear answer: "No they
aren't", so there is no need to make this a TypeError (while the question
"Is 42 larger than 'foobar'?" has no good answer.) I believe doing
something like this would roughly match how Python 3 works. (Edit: I see
now that this is mentioned in the FAQ, but I think it would be good to
reconsider this. It would solve most of my problems with this proposal.)
Besides the argument in the FAQ, having the == and != return do a type
check, means there are a lot more cases where the behavior changes rather
than that a TypeError is thrown. Currently
"foobar" == 0 returns true,
but this would make it return false. So would
1 == true,
"0" == 0 and
"0" == false. To reduce the cases where the behavior changes to a
minimum, it's better to throw TypeErrors for == and !=.
- String increment seems like a pretty niche use case, and I believe that
many people find the overflow behavior quite surprising. I think it may be
better to forbid string increment under strict_operators.
- A similar argument can be made for the use of &, | and ^ on strings.
While I have some personal fondness for these, in practical terms these are
rarely used and may be indicative of a bug. I think both for string
increment and string and/or/xor it may be better to expose these as
functions so their use is more explicit.
These operators make it very easy to work with binary data as strings in
PHP. In other languages you have to work with byte arrays, which is a major
pain. They're also very intuitive;
"wow" & "xul" is the same as
chr(ord('w') & ord('x')) . chr(ord('o') & ord('u')). chr(ord('w') & ord('l')). I think these should stay.