Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127859
Precedence: bulk
MIME-Version: 1.0
References: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com>
 <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk> <CAOV5rgaKkR-y3Hu9Fs0_ty2wT5MoYLDJ_OTH-nDBA-g__t4VEA@mail.gmail.com>
 <AE53E18F-A195-4D40-8BD1-D75AAFE07F92@rwec.co.uk> <CAOV5rgYNXLvBaBW50KpzNTFC7wEVBC0+QdSPmKhqsdGyc3uPWQ@mail.gmail.com>
 <38e57171-fc2e-4d79-8614-0b1c5a2efc72@app.fastmail.com> <CAOV5rgbCVFHPivdKn7oWbKbOD9yaGXu2h5jgoGg9vmBz=mq3Gw@mail.gmail.com>
 <e0a9d131-f24d-4d0d-83f9-08f023530d21@app.fastmail.com>
In-Reply-To: <e0a9d131-f24d-4d0d-83f9-08f023530d21@app.fastmail.com>
Date: Thu, 3 Jul 2025 16:39:12 +0200
Message-ID: <CAOV5rgaCbUmSsh=YGPtbvijOa+fCZKMPudGnzhThCg54tt89FA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fe5ef00639075735"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--000000000000fe5ef00639075735
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

I have updated the RFC to include a section outlining the migration path
<https://wiki.php.net/rfc/data_encoding_api#migration_path>. Since the
proposed migration strategy for base64_decode() *may be considered
controversial*, I plan to submit it as an *optional vote*=E2=80=94allowing
contributors to decide specifically on that aspect. If the optional vote
fails, I want to ensure that the rest of the proposal is *not rejected*
solely due to disagreements over the migration approach for this function.

Best regards,
Ignace

On Wed, Jul 2, 2025 at 9:57=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> On Wed, Jul 2, 2025, at 2:25 PM, ignace nyamagana butera wrote:
> >>
> >> I don't think it needs to be added to the enum, necessarily.  Just mak=
e
> it a nullable argument to base64_decode.
> >>
> >> function base64_decode(string $string, bool $strict =3D false,
> ?DecodingMode =3D null): string|false
> >>
> >> That would leave the default behavior of the function intact, but also
> allows switching it over to either of the new modes (which would then jus=
t
> defer to the new implementations).  And we wouldn't need to deal with
> "disallowed" modes on the new functions.
> >>
> > Hi Larry,
> >
> > The goal is not to change the signature of the existing `base64_encode`
> > function, but rather to preserve its current non-strict behavior within
> > the new API. This is intended to ensure a smoother transition from the
> > existing API to the proposed one. Therefore, we shouldn=E2=80=99t alter=
 or
> > retrofit the existing function. Instead, the focus should be on
> > providing a clear migration path for users, which is why the addition
> > of a `DecodingMode::Unsafe` case is being proposed.
> >
> > If I were to follow your suggestion, I would have proposed an
> > alternative signature like this:
> >
> > ```
> > base64_encode(string $string, bool|DecodingMode $strict =3D false);
> > ```
>
> That would work, too.  My point is just trying to avoid
> DecodingMode::Unsafe as a thing that has to then be checked for and
> rejected by the new functions.  That feels like clunkiness that we should
> be able to avoid.  So with that signature, false would still use the
> existing "unsafe" mode; there's no enum case for "old unsafe logic", just
> for the new-correct modes.
>
> --Larry Garfield
>

--000000000000fe5ef00639075735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><a href=3D"/"></a>Hi all,<div><br></div><div>I have update=
d the RFC <a href=3D"https://wiki.php.net/rfc/data_encoding_api#migration_p=
ath">to include a section outlining the migration path</a>. Since the propo=
sed migration strategy for <code>base64_decode()</code> <strong>may be cons=
idered controversial</strong>, I plan to submit it as an <strong>optional v=
ote</strong>=E2=80=94allowing contributors to decide specifically on that a=
spect. If the optional vote fails, I want to ensure that the rest of the pr=
oposal is <strong>not rejected</strong> solely due to disagreements over th=
e migration approach for this function.</div><div><br></div><div>Best regar=
ds,</div><div>Ignace</div></div><br><div class=3D"gmail_quote gmail_quote_c=
ontainer"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 2, 2025 at 9:57=
=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">la=
rry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">On Wed, Jul 2, 2025, at 2:25 PM, ignace nyamagana buter=
a wrote:<br>
&gt;&gt; <br>
&gt;&gt; I don&#39;t think it needs to be added to the enum, necessarily.=
=C2=A0 Just make it a nullable argument to base64_decode.<br>
&gt;&gt; <br>
&gt;&gt; function base64_decode(string $string, bool $strict =3D false, ?De=
codingMode =3D null): string|false<br>
&gt;&gt; <br>
&gt;&gt; That would leave the default behavior of the function intact, but =
also allows switching it over to either of the new modes (which would then =
just defer to the new implementations).=C2=A0 And we wouldn&#39;t need to d=
eal with &quot;disallowed&quot; modes on the new functions.<br>
&gt;&gt; <br>
&gt; Hi Larry,<br>
&gt;<br>
&gt; The goal is not to change the signature of the existing `base64_encode=
` <br>
&gt; function, but rather to preserve its current non-strict behavior withi=
n <br>
&gt; the new API. This is intended to ensure a smoother transition from the=
 <br>
&gt; existing API to the proposed one. Therefore, we shouldn=E2=80=99t alte=
r or <br>
&gt; retrofit the existing function. Instead, the focus should be on <br>
&gt; providing a clear migration path for users, which is why the addition =
<br>
&gt; of a `DecodingMode::Unsafe` case is being proposed.<br>
&gt;<br>
&gt; If I were to follow your suggestion, I would have proposed an <br>
&gt; alternative signature like this:<br>
&gt;<br>
&gt; ```<br>
&gt; base64_encode(string $string, bool|DecodingMode $strict =3D false);<br=
>
&gt; ```<br>
<br>
That would work, too.=C2=A0 My point is just trying to avoid DecodingMode::=
Unsafe as a thing that has to then be checked for and rejected by the new f=
unctions.=C2=A0 That feels like clunkiness that we should be able to avoid.=
=C2=A0 So with that signature, false would still use the existing &quot;uns=
afe&quot; mode; there&#39;s no enum case for &quot;old unsafe logic&quot;, =
just for the new-correct modes.<br>
<br>
--Larry Garfield<br>
</blockquote></div>

--000000000000fe5ef00639075735--