Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127024
Content-Type: multipart/alternative;
 boundary="------------KYn390d6f51CZAwdfpP0i8aF"
Message-ID: <b077e093-0816-4881-9dac-eb19689fa45f@seld.be>
Date: Wed, 2 Apr 2025 09:33:27 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC brainstorm] Approximately equals operator
To: internals@lists.php.net
References: <4a3c6ce7-102d-4cfe-a7a8-35630715b870@gmail.com>
Content-Language: fr
In-Reply-To: <4a3c6ce7-102d-4cfe-a7a8-35630715b870@gmail.com>
From: j.boggiano@seld.be (Jordi Boggiano)

This is a multi-part message in MIME format.
--------------KYn390d6f51CZAwdfpP0i8aF
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01.04.2025 00:03, Niels Dossche wrote:
> We live in an imperfect world, and we often approximate data, but neither `==` nor `===` are ideal comparison operators to deal with these kinds of data.

I am late to the party here, but in all seriousness when I read the subject my initial thought was that this was gonna be about adding a ~= operator to clearly show intent (does the same as == though), allowing us to simultaneously deprecate ==. Then in next major we can make == mean strict equal, deprecate ===, and you're left with == or ~=, which seems cleaner to me as you know nobody typed ~= accidentally while they meant ===.

Anyway, while (maybe..) a less goofy idea it is probably just as unlikely to make it through BC concerns.

Best,
Jordi

--------------KYn390d6f51CZAwdfpP0i8aF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 01.04.2025 00:03, Niels Dossche
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:4a3c6ce7-102d-4cfe-a7a8-35630715b870@gmail.com">
      <pre wrap="" class="moz-quote-pre">We live in an imperfect world, and we often approximate data, but neither `==` nor `===` are ideal comparison operators to deal with these kinds of data.
</pre>
    </blockquote>
    <pre wrap="" class="moz-quote-pre" style="white-space: pre-wrap;">I am late to the party here, but in all seriousness when I read the subject my initial thought was that this was gonna be about adding a ~= operator to clearly show intent (does the same as == though), allowing us to simultaneously deprecate ==. Then in next major we can make == mean strict equal, deprecate ===, and you're left with == or ~=, which seems cleaner to me as you know nobody typed ~= accidentally while they meant ===.

Anyway, while (maybe..) a less goofy idea it is probably just as unlikely to make it through BC concerns.

Best,
Jordi</pre>
  </body>
</html>

--------------KYn390d6f51CZAwdfpP0i8aF--