Hi Rob,
> Instead of creating a BC break (which will probably affect older, less
> maintained libraries the most), why not create new constants and deprecate
> the old constants?
I see, it makes sense to provide a transition period for users.
Would it be a good idea to deprecate it in 8.4 and
Link to the PR https://github.com/php/php-src/pull/13698
I think padding should be optional (on by default to keep BC)
Of course in user land, simple to write
$enc = trim(base64_encode('foo'), '=');
This proposal allow to simply use
$enc = base64_encode('foo', PHP_BASE64_NO_PADDING);
And also expose it for extension as
PHPAPI extern
On Wednesday, 28 February 2024 at 15:24, Gina P. Banyard
wrote:
> Hello internals,
>
> I have opened the vote for the "Deprecate implicitly nullable parameter
> types" RFC:
> https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
>
> It will run for two weeks until the 13th of March
Hi
On 3/13/24 17:06, Remi Collet wrote:
Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635
It may seems ugly to add and remove th padding char
Is a RFC needed for such a minor feature ?
Previous related discussion:
On 12/03/2024 22:43, Larry Garfield wrote:
It's slightly different, yes. The point is that the special behavior of a hook is
disabled if you are within the call stack of a hook, just like the special behavior of
__get/__set is disabled if you are within the call stack of __get/__set. What
