> On Nov 10, 2025, at 22:43, Daniel Gustafsson <[email protected]> wrote:
>
>> On 10 Nov 2025, at 10:06, Chao Li <[email protected]> wrote:
>>> On Nov 8, 2025, at 14:25, Sugamoto Shinya <[email protected]> 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/
