On 04/03/2021 13:17, Nikita Popov wrote:
A disadvantage of narrowing the definition in such a fashion is that
it introduces a discrepancy with (float) casts. I believe these
currently recognize the same values, with the exception that (float)
discards trailing garbage.
I don't think that's
On Thu, Mar 4, 2021 at 1:03 PM Rowan Tommins
wrote:
> On 04/03/2021 10:54, Nikita Popov wrote:
> > The main one that comes to mind is something like '0' == '0.0'. However,
> > the real problem is something else: Comparison behavior doesn't affect
> just
> > == and !=, but also < and >. And I can
On 04/03/2021 10:54, Nikita Popov wrote:
The main one that comes to mind is something like '0' == '0.0'. However,
the real problem is something else: Comparison behavior doesn't affect just
== and !=, but also < and >. And I can see how people would want '2' < '10'
to be true (numeric comparison)
I actually do a lot of lexicographical comparison with ISO8601 date
strings.
I also have numerical string comparisons, but the truth is I didn't think
they would be cast to integers so that is a potential bug in my code. When
I use < on strings I expect that they will both compare as strings. In
ot
On Thu, Mar 4, 2021 at 11:54 AM Nikita Popov wrote:
> On Thu, Mar 4, 2021 at 10:54 AM Christian Schneider
> wrote:
>
>> Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
>> > On Mar 3, 2021, at 14:25, Kamil Tekiela wrote:
>> >>
>> >> when both are strings then chances are that this is an error.
>> >
On Thu, Mar 4, 2021 at 10:54 AM Christian Schneider
wrote:
> Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
> > On Mar 3, 2021, at 14:25, Kamil Tekiela wrote:
> >>
> >> when both are strings then chances are that this is an error.
> >
> > Except when comparing two values from sources known to provi
Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
> On Mar 3, 2021, at 14:25, Kamil Tekiela wrote:
>>
>> when both are strings then chances are that this is an error.
>
> Except when comparing two values from sources known to provide numbers as
> strings, such as form input and database results. :-)
On 04/03/2021 00:37, Ben Ramsey wrote:
On Mar 3, 2021, at 14:25, Kamil Tekiela wrote:
when both are strings then chances are that this is an error.
Except when comparing two values from sources known to provide numbers as
strings, such as form input and database results. :-)
The juggling
On Mar 3, 2021, at 14:25, Kamil Tekiela wrote:
>
> when both are strings then chances are that this is an error.
Except when comparing two values from sources known to provide numbers as
strings, such as form input and database results. :-)
Cheers,
Ben
signature.asc
Description: Message sig
Am 03.03.2021 um 21:25 schrieb Kamil Tekiela :
> Sorry Nikita, but adding special handling for edge-cases is only going to
> make things messier.
I didn't want to say that, as there is plenty of code out there who might fall
in this trap this intermediate measure might still make sense.
The good
Oh, I like Chris's idea. Yes, please.
Let's deprecate numerical comparison when both operands are strings and
remove that behaviour in PHP 9.0.
Type juggling can be useful when one of them is an integer or float but
when both are strings then chances are that this is an error.
Sorry Nikita, but add
Am 03.03.2021 um 19:21 schrieb Stanislav Malyshev :
> Nobody who applies == to strings and expects it to work out as stri g
> comparison is doing the right thing. If you apply == to hex-encoded hashes,
> that code is fubar, and fixing one particular corner case won't rescue it. So
> I wonder if
Hi!
PHP's == comparison semantics for strings have a peculiar edge-case, where
comparisons of the form "0e123" == "0e456" return true, because they are
interpreted as floating point zero numbers. This is problematic, because
strings of that form are usually not numbers, but hex-encoded hashes or
> On Mar 3, 2021, at 08:04, Nikita Popov wrote:
>
> Hi internals,
>
> PHP's == comparison semantics for strings have a peculiar edge-case, where
> comparisons of the form "0e123" == "0e456" return true, because they are
> interpreted as floating point zero numbers. This is problematic, because
>
14 matches
Mail list logo
