Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129905 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 203DB1A00BC for ; Fri, 23 Jan 2026 17:33:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769189605; bh=WiJMFYh+jDJ5FcISMTeXi1d1hNAiOxF7TfLF01F3FPU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=L8mdufED630fLE8EDmwysmc9rmJWKqIBakbUlgsZU44BJ3ujFtTgrJpbEmWsjZcHo atms+UnU9H2ieM0ZYOrPUgKSZl7uwqezYkOYmub4CR6HN5tR3jL8a+e2G231l5lc2o 8ahojolxcIwHtyJ7rRLH11DeD/I4w+uObszwUQjFLUFSkcPsxYt8ppOke4QtRbG3P1 RoVeWaHyzvlRjKnxGjLfTaUz78urjbyRBszcgvalA75mcfxrpQONrzcRxaZEx59qg1 nyJrAih80VkwZ9y1t+3tORJYi2h2n/cJocWkCmq5XdklQMobWTPEeCxD2RFEmzMxrC HUzKXZvshB1cw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 484E41804DA for ; Fri, 23 Jan 2026 17:33:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from venus.thgnet.it (venus.thgnet.it [159.69.22.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 23 Jan 2026 17:33:23 +0000 (UTC) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by venus.thgnet.it (Postfix) with ESMTPSA id A80BB3EFF0 for ; Fri, 23 Jan 2026 18:33:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=giacobbi.net; s=venus; t=1769189596; bh=WiJMFYh+jDJ5FcISMTeXi1d1hNAiOxF7TfLF01F3FPU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OU2RC/Cah+M6x5tfyBvMSV2YS1kJ2dCiUZ9O6RoBew3cZlfSmbVvgtirMAdcXvnpP HyxPOLt118w8VheaR8onTysHpPlS3Y3adMO9X1a0hSk06eKd65vzAHbkRaU/vupbPi +nPBoy5J0iFehHdkobs0mElR9wfnjMAX7ozkXt9E= Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-59b76844f89so2390540e87.1 for ; Fri, 23 Jan 2026 09:33:16 -0800 (PST) X-Gm-Message-State: AOJu0YwbZx6HJ7SdyGFTs6cBZjX4gC6jlkkRbd2PQT6367Dtej1CWmKf xCE6taNrzoo1sd85vMAK4WYkSZ0vXZdZF5sur3RQZrJOfdIeCZUaA1q+uiHheQYGty4M6o/LtWj regJcm/HgzTg4wFDDWqA/HuhiQlkPbzg= X-Received: by 2002:a05:6512:3c9c:b0:59d:e371:5374 with SMTP id 2adb3069b0e04-59de49181cfmr1176308e87.25.1769189596070; Fri, 23 Jan 2026 09:33:16 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 23 Jan 2026 18:33:05 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QjsjvFT0oVESCFCIpALiOvWvpSlLZ-NMR7vmR4OhYfqnsxQxTJRLhQrcSg Message-ID: Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict Mode To: Alexandre Daubois Cc: PHP internals list Content-Type: multipart/alternative; boundary="0000000000006a0f180649118d24" From: giovanni@giacobbi.net (Giovanni Giacobbi) --0000000000006a0f180649118d24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2026, 15:17 Alexandre Daubois wrote: > Hi Lynn, thank you for sharing your thoughts. > > Le ven. 23 janv. 2026 =C3=A0 12:44, Lynn a =C3=A9crit = : > > What's the expected behavior of `(int) '001'` and `(int) 1.`? I would > expect both to still be valid integers, but I can't tell from this RFC if > those scenarios would be affected. The first scenario is common with > "ZEROFILL" database columns, and the latter is a scenario I recently foun= d > being used to get a valid int from user input if considered number-ish an= d > switch between whole number vs decimal behavior. > > They will be indeed valid integers. There is no lossy cast here: "001" > and "1." are valid integers and expected. > According to whose definition of "lossy" is that not a lossy conversion? The only non lossy conversion is when (string) (int) $value =3D=3D=3D $valu= e Everything else *is* lossy. The number of zeroes in front is information, so is the whitespace around the number. Your interpretation of lossy seems completely arbitrary to me. My opinion is that the BC break of this proposal in its current form would be insane and unreasonable. --0000000000006a0f180649118d24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 23, 2026, 15:17 Alexandre Da= ubois <alex.daubois+php@= gmail.com> wrote:
Hi Lynn, thank you for sharing your thoughts.

Le ven. 23 janv. 2026 =C3=A0 12:44, Lynn <kjarli@gmail.com> a =C3= =A9crit :
> What's the expected behavior of `(int) '001'` and `(int) 1= .`? I would expect both to still be valid integers, but I can't tell fr= om this RFC if those scenarios would be affected. The first scenario is com= mon with "ZEROFILL" database columns, and the latter is a scenari= o I recently found being used to get a valid int from user input if conside= red number-ish and switch between whole number vs decimal behavior.

They will be indeed valid integers. There is no lossy cast here: "001&= quot;
and "1." are valid integers and expected.
<= /div>

According to whose defin= ition of "lossy" is that not a lossy conversion? The only non los= sy conversion is when (string) (int) $value =3D=3D=3D $value

Everything else *is* lossy. The numbe= r of zeroes in front is information, so is the whitespace around the number= .

Your interpretation of= lossy seems completely arbitrary to me.

<= div dir=3D"auto">My opinion is that the BC break of this proposal in its cu= rrent form would be insane and unreasonable.

--0000000000006a0f180649118d24--