Re: [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

Hi all, I have a few suggestions, starting with naming improvements: - Forgiving instead of Lenient (align with https://infra.spec.whatwg.org/#forgiving-base64) - Shorten the option names; one example would be Variable/Constant instead of Unprotected/ConstantTime, but I think most could be rethinked - $input or $data instead of $decoded (could actually do the same instead of $encoded, but that one doesn't feel as wrong) - Not strictly about naming, but it similarly feels wrong that UnableToDecodeException extends EncodingException (which seems to have no purpose) However, I'm not a fan of how these simple functions have so many option flags ... it feels forced, trying to accomodate too much at once. I'd rather have discrete functions, like base64_*() and base64url_*() - I chose this example because base64 and base64url also have arguably different desirable defaults for padding; almost all pad-stripping I've seen in the wild has been for the purposes of converting to base64url. On a semi-related note, I'm not sure if including the IMAP variant isn't complicating things for no good reason (it is extra-niche, and we have imap_binary/base64() already). Also, the RFC doesn't specify whether DecodingMode::Strict would cause an error in case of missing padding? That being said, I'm very glad to see this! Cheers, Andrey.