Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124063
Precedence: bulk
MIME-Version: 1.0
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <E146A171-CFA6-4E3F-91AA-2ACE7710A6D9@newclarity.net> <dbGe34EpQtjyP7ja7aUHnZYwmtupxeLd7EoOv3JjQMSh_UqoMrbqo5PkxrlIiaXJePC1-TfLyyblz5QDM13OkitgBqKPuSvh28WiJFh7qJI=@gpb.moe>
 <B958318C-B61D-4618-BA7D-3BF204C5B3CD@newclarity.net> <ca140b2c-51ff-4217-8f66-23f877ac0cb8@gmail.com>
 <3f230c9b-7aca-4bce-ab2a-544a10bf128f@bastelstu.be>
In-Reply-To: <3f230c9b-7aca-4bce-ab2a-544a10bf128f@bastelstu.be>
Date: Sun, 30 Jun 2024 07:23:12 +1000
Message-ID: <CAKVXxD8k0aJj9RisUOnvFo6qynX1eyO4whPz5jc4wyknqw83tQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Markus Podar <markus.podar@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000066433f061c0df94a"
From: mickmackusa@gmail.com (mickmackusa)

--00000000000066433f061c0df94a
Content-Type: text/plain; charset="UTF-8"

>
> If one can easily use a function incorrectly in a way that is not
> *immediately* apparent, then I consider the function to be badly
> designed.
>

Does that philosophy also cover preg_quote()?  I've lost count of the
number of times that I've seen it used in Stack Overflow answers without a
second parameter (including array_map('preg_quote', $array)) and its
returned value used in a regex that has foward slashes as delimiters.

Additionally, it is an unintuitively named function; it doesn't actually
"quote" anything -- it \e\s\c\a\p\e\s characters.  This makes life
unnecessarily harder for devs who are new to PHP who need to find the regex
escaping function.

Would it be reasonable to create `preg_escape()` which also (sometimes
unnecessrily) includes the (de facto default delimiter) forward slash in
its default list of escaped characters so that preg_quote() could
eventually be deprecated?  As far as I know this would do no harm, will
prevent holes in code, and make PHP more intuitive.

Mick

>

--00000000000066433f061c0df94a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">If one can easily use a function incorrectly in a way that is not <br=
>
*immediately* apparent, then I consider the function to be badly <br>
designed.=C2=A0<br></blockquote></div></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Does that philosophy also cover preg_quote()?=C2=A0 I&#39;ve=
 lost count of the number of times that I&#39;ve seen it used in Stack Over=
flow answers without a second parameter (including array_map(&#39;preg_quot=
e&#39;, $array)) and its returned value used in a regex that has foward sla=
shes as delimiters.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Addi=
tionally, it is an unintuitively named function; it doesn&#39;t actually &q=
uot;quote&quot; anything -- it \e\s\c\a\p\e\s characters.=C2=A0 This makes =
life unnecessarily harder for devs who are new to PHP who need to find the =
regex escaping function.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Would it be reasonable to create `preg_escape()` which also (sometimes unn=
ecessrily) includes the (de facto default delimiter) forward slash in its d=
efault list of escaped characters so that preg_quote() could eventually be =
deprecated?=C2=A0 As far as I know this would do no harm, will prevent hole=
s in code, and make PHP more intuitive.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Mick</div><div dir=3D"auto"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
</blockquote></div></div></div>

--00000000000066433f061c0df94a--