On Mon, 6 Apr 2026 at 13:55, Andrew Dunstan <andrew@dunslane.net> wrote:
> There was quite a deal of discussion around this mechanism. See Euler's
> review at [1] and follow-up at [2] for the original discussion of the
> VARIADIC option-parsing design and the use cases it was meant to
> address. I'm prepared to revisit it is there's a strong consensus on the
> point.
Thanks for those links. I had not seen that part of the discussion. But
I only see an explanation of why these functions are configurable with
optional key+value pairs in their arguments. I think that makes sense,
and I totally agree that we should do that.
The thing I'm questioning is whether we need a new way of providing
key+value pairs as optional arguments to functions. IMO we already had a
perfectly fine one. Introducing another adds complexity (both to the
code and to the user) and I don't see any compelling reason to do so.
Attached is a patch with roughly what I have in mind instead. By doing
this we can also make the functinos STRICT, so that we don't have to
worry about handling NULL values for the first argument.
Afaict this named parameter approach only has benefits over the VARIADIC
argument one. But if I'm wrong about that, please let me know.
