Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127848
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 02 Jul 2025 14:54:54 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e0a9d131-f24d-4d0d-83f9-08f023530d21@app.fastmail.com>
In-Reply-To: 
 <CAOV5rgbCVFHPivdKn7oWbKbOD9yaGXu2h5jgoGg9vmBz=mq3Gw@mail.gmail.com>
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>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 2, 2025, at 2:25 PM, ignace nyamagana butera wrote:
>>=20
>> I don't think it needs to be added to the enum, necessarily.  Just ma=
ke it a nullable argument to base64_decode.
>>=20
>> function base64_decode(string $string, bool $strict =3D false, ?Decod=
ingMode =3D null): string|false
>>=20
>> That would leave the default behavior of the function intact, but als=
o allows switching it over to either of the new modes (which would then =
just defer to the new implementations).  And we wouldn't need to deal wi=
th "disallowed" modes on the new functions.
>>=20
> Hi Larry,
>
> The goal is not to change the signature of the existing `base64_encode=
`=20
> function, but rather to preserve its current non-strict behavior withi=
n=20
> the new API. This is intended to ensure a smoother transition from the=20
> existing API to the proposed one. Therefore, we shouldn=E2=80=99t alte=
r or=20
> retrofit the existing function. Instead, the focus should be on=20
> providing a clear migration path for users, which is why the addition=20
> of a `DecodingMode::Unsafe` case is being proposed.
>
> If I were to follow your suggestion, I would have proposed an=20
> 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::Un=
safe 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" mod=
e; there's no enum case for "old unsafe logic", just for the new-correct=
 modes.

--Larry Garfield