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 >
