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
