Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127841
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 02 Jul 2025 11:16:53 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <38e57171-fc2e-4d79-8614-0b1c5a2efc72@app.fastmail.com>
In-Reply-To: 
 <CAOV5rgYNXLvBaBW50KpzNTFC7wEVBC0+QdSPmKhqsdGyc3uPWQ@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>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 2, 2025, at 10:10 AM, ignace nyamagana butera wrote:
>> > Perhaps we should include an option in the new API to emulate the old behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated with a note in the manual, similar to the MT_RAND_PHP mode in the Randomizer API <https://www.php.net/manual/en/random-engine-mt19937.construct.php>
>
> If I follow your reasoning, this would imply introducing a new case, 
> `DecodingMode::Unsafe`, in the `DecodingMode` enum. This mode would 
> replicate the current default behavior of `base64_decode`, but only 
> within `Encoding\base64_decode`.
>
> ```php
> echo base64_decode('dG9===0bw??'); // returns 'toto'
> //would be portable to the new API using the following code
> echo Encoding\base64_decode('dG9===0bw??', decodingMode: 
> Encoding\DecodingMode::Unsafe); // returns 'toto'
> ```
>
> I would therefore propose that, for all other decoding functions, any 
> attempt to use `DecodingMode::Unsafe` must result in an 
> `UnableToDecodeException` being thrown.

I don't think it needs to be added to the enum, necessarily.  Just make it a nullable argument to base64_decode.

function base64_decode(string $string, bool $strict = false, ?DecodingMode = 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 just defer to the new implementations).  And we wouldn't need to deal with "disallowed" modes on the new functions.

> Should this deprecation take place during the PHP 8 cycle, with removal 
> targeted for PHP 9? Or would it be more appropriate to defer the 
> deprecation to the PHP 9 cycle, aiming for removal in PHP 10?  
> Alternatively, should a second vote be held to determine the
> preferred deprecation timeline?

Since we don't know when PHP 9 will be yet (Grrr...), I'd lean toward a secondary vote or punting it to the usual mass-deprecation RFC that often happens.  (Side note: This is why we need a regular schedule for major releases.)

--Larry Garfield