Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127820
Feedback-ID: id5114917:Fastmail
Date: Tue, 01 Jul 2025 12:06:54 +0100
To: PHP Internals List <internals@lists.php.net>
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D=5BDISCUSSION=5D_Add_?=
 =?US-ASCII?Q?RFC_4648_compliant_data_encoding_API?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com>
References: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com>
Message-ID: <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 19 June 2025 12:01:04 BST, ignace nyamagana butera <nyamsprod@gmail=2Ec=
om> wrote:
>RFC proposal link: https://wiki=2Ephp=2Enet/rfc/data_encoding_api

Thanks for working on this, I have often had to implement base64url and be=
en frustrated it's not just a built-in option=2E

I like the look of the new API=2E Using namespaced enums is currently quit=
e verbose, but that's something we could try to fix at at the language leve=
l - e=2Eg=2E Swift has some nice inference rules, so you can write the equi=
valent of base64_encode($string, ::UrlSafe)=2E

One thing I think the RFC should mention is the future of the existing bas=
e64_encode/decode functions=2E Am I right in thinking that with one paramet=
er, the new namespaced versions will be identical to the old? If so, we hav=
e the option to make the existing functions aliases for the new=2E Or, we c=
an leave them as-is, but plan to deprecate them=2E What we probably don't w=
ant is to indefinitely have two versions with such similar names but differ=
ent signatures=2E

Rowan Tommins
[IMSoP]