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*—allowing
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 PM Larry Garfield <la...@garfieldtech.com>
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 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.
> >>
> > 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’t 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 = 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
>

Reply via email to