> On Nov 10, 2025, at 22:43, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> On 10 Nov 2025, at 10:06, Chao Li <li.evan.chao@gmail.com> wrote:
>>> On Nov 8, 2025, at 14:25, Sugamoto Shinya <shinya34892@gmail.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
witha 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
isto 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
tohardcoding 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/
