> It is a well-known feature that you can work with such data without
previously converting it explicitly to some number type.
I'm not requesting to change this: if you're doing string("3.5") + int(7),
you should still get float(10.5). What I'm suggesting we change, is
comparison of numbers and decimal strings.
Thinking about this a bit more, what about following JavaScript semantics?
I find them really good in this respect:
- when comparing two strings, always use strcmp():
var_dump("42" == "42.0"); // false
var_dump("3" < "23"); // false
- when comparing a number with a string, cast the string to a number, then
compare:
var_dump(3 < "23"); // true
var_dump("3" < 23); // true
var_dump(42 == "42"); // true
var_dump(42.0 == "42"); // true
var_dump(42.5 == "42.5"); // true
var_dump(42 == "42.0"); // true
- if the string does not represent a valid number, always return false:
var_dump(42 == "42x"); // false
var_dump(42 == "x42"); // false
var_dump(1 >= "abc"); // false
var_dump(1 < "abc"); // false
Note: JavaScript actually allows leading & trailing whitespace around the
number:
var_dump(42 == " 42 "); // true
On this last point, I'm not sure whether we should allow both leading &
trailing whitespace, or disallow both of them.
Other than that, I love the way they handle implicit conversions here. It's
so much more understandable, easy to remember, and less prone to errors IMO.
Ben
On Wed, 27 Mar 2019 at 11:28, Claude Pache <[email protected]> wrote:
>
>
> > Le 27 mars 2019 à 00:09, Benjamin Morel <[email protected]> a
> écrit :
> >
> > - I would also strongly suggest that 2 strings are always compared
> > byte-by-byte; IMO it does (*somehow*) make sense that 42 == "42.0", but
> it
> > DOES NOT make sense that "42" == "42.0". (...)
>
> There are many ways to obtain numeric data in the form of a string from
> external sources (HTML form, database, CSV, ...) and even internal sources
> (bcmath, ...)—and note that, even when such numerical data may have a
> decimal part, it does *not* mean that they are imprecise. It is a
> well-known feature that you can work with such data without previously
> converting it explicitly to some number type. That works pretty well in PHP
> (well, except that you get intermittent obscure bugs when some third-party
> code in the same thread plays with setlocale(), but that's another
> story...) If we cease to compare numeric strings numerically, I expect that
> much code will begin to break more or less subtly, and will need to be
> thoroughly reviewed in order to be corrected. We must not change that.
>
> The core issue is that “==” is fundamentally ambiguous: should it compare
> as number, as string, as reference, ...? If we were to redesign PHP from
> scratch, we may decide other semantics than the current one (e.g., use
> distinct operators for comparing numerically and textually, as does Perl).
> But where we are now, the best thing to do is to follow the common wisdom:
> If you want to compare strings as strings, just use “===”. Or strcmp.
>
> —Claude
>
>
