Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions

> On Nov 10, 2025, at 22:43, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 10 Nov 2025, at 10:06, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>> On Nov 8, 2025, at 14:25, Sugamoto Shinya <shinya34892(at)gmail(dot)com> wrote:
>
>>> This patch adds an error hint listing the valid encoding names,
>>> so users can immediately see the supported options.
>
> +1.
>
>> I think hardcoding the encoding list is fragile. AFAIK, “base64url” was newly added just a couple of months ago.
>>
>> The list is defined in encode.c (search for enclist in the file), I guess we can add a function to return a string with a encoding names.
>
> New encodings are added very infrequently, we can revisit this if that changes
> but till then I think the simplicity of a hardcoded string is preferrable.
>

I’m not convinced that a hardcoded string is actually better. In fact, the less often something changes, the easier it is to miss updating it when we need to.

If we add a helper function to build the list of supported encodings:

* The function is small and straightforward — trivial to implement.
* The function doesn’t run in any performance-critical paths, so no meaningful cost there.
* The encoding names are plain ASCII identifiers and effectively the same across languages, so there’s no real benefit to hardcoding them for i18n purposes either.

So I still think the helper function seems cleaner and less error-prone than a hardcoded string.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/