Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127658
Precedence: bulk
MIME-Version: 1.0
References: <CAOV5rgYu8Z+Nqifavvg9O3t=153zpa_3FXR3e=-b9qvKdXT=CQ@mail.gmail.com>
 <CAJmy8YE4F3QwnWqeW2+VBnBV8=nj2zJcD8x=Bamzf2JSwB2cpQ@mail.gmail.com>
In-Reply-To: <CAJmy8YE4F3QwnWqeW2+VBnBV8=nj2zJcD8x=Bamzf2JSwB2cpQ@mail.gmail.com>
Date: Thu, 12 Jun 2025 23:05:08 +0530
Message-ID: <CANLbj-paCD_Hk0ZCm=YrJSSO+bKU6rWGD3tae-izKgwifnp2Aw@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Support for RFC4648 in PHP
To: Hans Henrik Bergan <divinity76@gmail.com>
Cc: ignace nyamagana butera <nyamsprod@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: ayesh@php.watch (Ayesh Karunaratne)

>
> Why do it in core?
> Is userland base16/base32 performance unsatisfactory?

Even if the performance is satisfactory, having this in core can help
user-land code to get rid of their own implementations (which they
often do, to be URL-safe, for example).

I imagine native implementations can make use of CPU SIMD acceleration
as well, like we already do for the current base64 functions.

The initial message also mentions adding this functionality into a
separate namespace, so I'm quite positive with this proposal. Even
more so than the previous proposals that proposed to add new
parameters to the base64 functions.