Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127795 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 976C41A00BC for ; Mon, 30 Jun 2025 09:22:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1751275212; bh=G/P+P2jCZRweOrQdhiWinwAY22olCekirZUT1RwBthA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cf8Mdm7K3mogHrfaywj70A7ue1NUgA5Dfy9OKamzULXd7+rtDtfM6y4mGUlBBq8AC 3TeCQrKhk/0KVdSc17M2cWl26+mw8CsSGk6BibP9tP0N3Z1bogicUQtK0tOw4DH0xG lBBANxcF27U9rFZ6HoMlClRyisEpbiuU1985DMakR0n/n2QFYdL1uLL1vnSb3RJ0UO 2KctFJ4uw+UE5s9AljlSZ6H1nLeA84yziy6o6ZrwPidZ0RNmPbZwNmHpTYpPpj2Cem hi2zW1pDwdQYo0Ph+emJQXqy8iu+FO4ZDJkWskUR2CSETNB5OX1iW8SV5YP8/OI2j2 87PkARjVIUVDw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C516E18006C for ; Mon, 30 Jun 2025 09:20:07 +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.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 30 Jun 2025 09:19:57 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-32b3b250621so39170761fa.2 for ; Mon, 30 Jun 2025 02:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751275310; x=1751880110; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G/P+P2jCZRweOrQdhiWinwAY22olCekirZUT1RwBthA=; b=WwrFqv1Pnbj5AwquHfKQpBegErc8XhUXoskvXAR5aBn003iVuJkHc6Am3/LELPpaBk OF6mlPMbEqAdwYlXW+0bnN3nQyEAC/Rz6+p48JrDjQKHR8tmvRai4K9y6JZG2YGfDU3s bHyhzG5Pf66b19eDR+6ZLiEG47r4e5jRczKu0M5wEV77fIYoWIc5X16cE4UUGoS/DCGI KwW5qT6YqrmOSrz/Rubc/Tjd0r4P5S9LZ94ZvfbJzu4+n0lWnPCG5itxyM6otbaL0EF1 tZ355+mKGRqz1CSeNbLIO4+4cPRwVKfzBjk8wk8OnVrM5KjTuF7/oHDqa/CwzXa+iqW9 SVKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751275310; x=1751880110; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G/P+P2jCZRweOrQdhiWinwAY22olCekirZUT1RwBthA=; b=g4X+Vk+rCF491sNceS6VLIF3PbCvqHOiXrceqn5M/Cjxg1CNTGKzUwIePAnPQVL8Qu DmO1cLJ2UG8WjRlTKBWoI271LsU3fN5RY3ElWgnGkJPOfOC7rvsxBxhE6GN+Plab/THl lB2AdZYsutqaOheNtZCVIMYYe3IZe4EqB4+zUBQjfq6H5YlYuXA4XsaczFbyzhuCOGBv /YQXeRx9ekc5q3vt62Dgd2S6GYDtiV7IMgEUzg1aAyF7BCs1qJ4JZhDZXmGKhRv5yhlu tAQmRr29RbCiV2ZKkcUTjQGDEbcWIl6XsGAu+JZGfr5yLZtlIuUXD1sRVJ8zmNw7b74W WIzw== X-Gm-Message-State: AOJu0Yy9AJ9W1kNQauN1AxF8akctcJv3tp9LCHu9xbLQ3BujkBTPHGAJ mtI4U0uNBSzYYpNXWrpLdbD0lQWLHrB146Ip6WrBAdOZChse+aocojtkp2D3PjC1Z7mAEsV0Ftz k0SeQI4AVoX+q8jhlT/YzdDP9m9A9faI= X-Gm-Gg: ASbGnctjSSb8U82qV5x7+XgeNAMrVs7qfyNjBfmlu54umK9wcAEaVaXdc2dYubBjpYH +OgPm3kp32psyNTO33MMu3uRzfflu7lh5lrMqEaIN0GUNB5Wp8kClaOT+LX73H1+j+H+weFgXnK tFotThUgIMrqe8oVyUtjSlNG84o6V+f275QV/+z4mVek7R X-Google-Smtp-Source: AGHT+IFqlUz53MH7F2409BcIO+UowBaha4pp+pA9IJvse/5FGP90BdyVmZHs5wyGCwk4IcQXMMchwSIHWajGZ7c9AGA= X-Received: by 2002:a05:651c:515:b0:32b:755e:6cce with SMTP id 38308e7fff4ca-32cdc4ef2c6mr36581891fa.19.1751275309156; Mon, 30 Jun 2025 02:21:49 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <3Yl0UGauXmKqk7s7Hqbv6iaXru-hZHf8Wj6VjwwihgRSaqZo5EZ2ndsOle-ae41C-lvnirynWt6PpuD7UJPL0zPCw18QHFE81Eb--fiiEbc=@gpb.moe> In-Reply-To: Date: Mon, 30 Jun 2025 11:21:37 +0200 X-Gm-Features: Ac12FXyhE71C_yZNYeQuv19anYmgUr8avH55fDtk_55DTejBd6xVXx3e_gvSa-A Message-ID: Subject: Re: [PHP-DEV][RFC] Deprecate type juggling to and from bool type within the function type juggling context To: "Gina P. Banyard" Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000b4cdf40638c68ed5" From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000b4cdf40638c68ed5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gina Le jeu. 26 juin 2025 =C3=A0 14:07, Gina P. Banyard a = =C3=A9crit : > On Monday, 2 June 2025 at 17:11, Gina P. Banyard > wrote: > > > Hello internals, > > > > This is the first RFC out of a set of type system related RFCs I want t= o > propose for PHP 8.5. > > It also used the recently enabled Markdown support on the wiki, so ther= e > might be a few oddities. > > > > The RFC proposes to deprecate implicit type coercions to and from the > bool type for other scalar types. > > This a "weak" mode change only, as when strict_types are enabled none o= f > these coercions can happen. > > > > Let me know what you think about it. > > > > RFC: https://wiki.php.net/rfc/deprecate-function-bool-type-juggling > > I have updated the RFC to version 0.2 that expands on it and addresses > some of the counterarguments which were said during the discussion. > RFC: https://wiki.php.net/rfc/deprecate-function-bool-type-juggling > > If there is no-follow up feedback, I will open the vote for it sometime > next week. > > Thanks for experimenting with this on https://github.com/symfony/symfony/pull/60890/files It's good to see that fitting this RFC requires a relatively small number of lines to change even on a codebase like Symfony. We're not at 100% but still nice. Yet, it IS a big bang in terms of deprecations to fix that this will trigger. Their number is super high, because these boolean conversions happen on hotpath / in loops. This reminds me of the mandatory "?" for arguments with null defaults: the change made sense from a language design PoV, but the impact was, and still is very high. It was and still is a very costly deprecation for the community, and it's not over yet. That made me say at conferences that this was maybe not a good idea... Looking at the diff above, I think I can draw two sets of changes: 1. the ones that patch a cast-to-bool 2. the ones that patch a cast-from-bool The latter, cast-from-bool, I think they're all useful improvements. While most likely harmless in all the specific cases of the PR, doing e.g. an strpos() on false feels hardly legit. I'm therefore sympathetic to making these changes. For cast-to-bool, I'm WAY less convinced. From the PR above, explicit casts like "return (bool) preg_match(...)" on a method that returns a "bool" or "= ( bool) ($this->loggedErrors & $type)" are a clear downgrade: it makes the typing PHP just more verbose without any real benefit. That doesn't look worth asking the whole ecosystem to fix those deprecations. It is especially hard to see this as an improvement when comparing to using the same expressions with e.g. the "if ()" operator, which doesn't need the explicit cast (and shouldn't of course). In the RFC, you write that its motivation is to allow making the bool type equivalent to the true|false union. To do so you propose to make the bool type always behave like in "strict" mode. Personally, I'm moot about the motivation. I understand it, but it looks inappropriate to push deprecations from this somewhat (IMHO) theoretical angle. The added friction would need way stronger arguments to be justified IMHO. Would it be possible to trigger the deprecation only in the cast-from-bool direction, and accept casts-to-bool as seamlessly as there are now? If yes, then would it also be possible to make the true and false types have the same behavior (aka non-strict in casts-to-bool direction - when not in strict mode of course)? If yes to both questions, then that'd look like a better outcome that'd still allow fulfilling your goal, while providing maximum value to the community. As is, the cost/benefit ratio doesn't make this RFC look worth it to me. Last but not least, I'm not sure it's a good idea to rush this into 8.5. This is a high-impact change. We should give some time to the discussion, understand the impact and explore variants. Merging this in 8.6 would also give a few more months for open-source projects to adapt to the change (since many do run their CI with the master branch of PHP to spot changes as early as possible.) Cheers, Nicolas PS: I'm going AFK for the next ~7 days. --000000000000b4cdf40638c68ed5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gina

Le=C2=A0jeu. 26 juin 202= 5 =C3=A0=C2=A014:07, Gina P. Banyard <internals@gpb.moe> a =C3=A9crit= =C2=A0:
On Monda= y, 2 June 2025 at 17:11, Gina P. Banyard <internals@gpb.moe> wrote:
> Hello internals,
>
> This is the first RFC out of a set of type system related RFCs I want = to propose for PHP 8.5.
> It also used the recently enabled Markdown support on the wiki, so the= re might be a few oddities.
>
> The RFC proposes to deprecate implicit type coercions to and from the = bool type for other scalar types.
> This a "weak" mode change only, as when strict_types are ena= bled none of these coercions can happen.
>
> Let me know what you think about it.
>
> RFC: https://wiki.php.net/rfc/dep= recate-function-bool-type-juggling

I have updated the RFC to version 0.2 that expands on it and addresses some= of the counterarguments which were said during the discussion.
RFC: https://wiki.php.net/rfc/deprecat= e-function-bool-type-juggling

If there is no-follow up feedback, I will open the vote for it sometime nex= t week.


Thanks for experimenting with this on= =C2=A0https= ://github.com/symfony/symfony/pull/60890/files

It's good to see that fitting this RFC requires a relatively small num= ber of lines to change even on a codebase like Symfony. We're not at 10= 0% but still nice.

Yet, it IS a big bang in terms = of deprecations to fix that this will trigger. Their number is super high, = because these boolean conversions=C2=A0happen=C2=A0on hotpath / in loops.

This reminds me of the mandatory "?" for = arguments with null defaults: the change made sense from a language design = PoV, but the impact was, and still is very high. It was and still is a very= costly deprecation for the community, and it's not over yet. That made= me say at conferences that this was maybe not a good idea...
Looking at the diff above, I think I can draw two sets of chang= es:
1. the ones that patch a cast-to-bool
2. the o= nes that patch a cast-from-bool

The latter, cast-f= rom-bool, I think they're all useful improvements. While most likely ha= rmless in all the specific cases of the PR, doing e.g. an strpos() on false= feels hardly legit. I'm therefore sympathetic to making these changes.=

For=C2=A0cast-to-bool, I'm WAY less convinced= . From the PR above, explicit casts like "return (bool) preg_match(...= )" on a method that returns a "bool" or "(bool) ($this-= >loggedErrors & $type)" are a clear downgrade: it makes t= he typing PHP just more verbose without any real benefit. That doesn't = look worth asking the=C2=A0whole ecosystem to fix those deprecations. It is= especially hard to see this as an improvement when comparing to using the = same expressions with e.g. the "if ()" operator, which doesn'= t need the explicit cast (and shouldn't of course).
=

In t= he RFC, you write that its motivation is to allow making the bool type equi= valent to the true|false union. To do so you propose to make the bool type = always behave like in "strict" mode.

Per= sonally, I'm moot about the motivation. I understand it, but it looks i= nappropriate to push deprecations from this somewhat (IMHO) theoretical ang= le. The added friction would need way stronger arguments to be justified IM= HO.

Would it be possible to trigger the deprecatio= n only in the cast-from-bool direction, and accept casts-to-bool as seamles= sly as there are now? If yes, then would it also be possible to make the tr= ue and false types have the same behavior (aka non-strict in=C2=A0casts-to-= bool direction - when not in strict mode of course)? If yes to both questio= ns, then that'd look like a better outcome that'd still allow fulfi= lling your goal, while providing maximum value to the community.
=
As is, the cost/benefit ratio doesn't make this RFC look= worth it to me.=C2=A0

Last but not least, I'm= not sure it's a good idea to rush this into 8.5. This is a high-impact= change. We should give some time to the discussion, understand the impact = and explore variants. Merging this in 8.6 would also give a few more months= for open-source projects to adapt to the change (since many do run their C= I with the master branch of PHP to spot changes as early as possible.)

Cheers,
Nicolas

PS:= I'm going AFK for the next ~7 days.
--000000000000b4cdf40638c68ed5--