Reordering new API's that have a libctx, propq

[Tim Hudson]

On Sat, Sep 5, 2020 at 8:45 PM Nicola Tuveri <nic.tuv at gmail.com> wrote:

> Or is your point that we are writing in C, all the arguments are
> positional, none is ever really optional, there is no difference between
> passing a `(void*) NULL` or a valid `(TYPE*) ptr` as the value of a `TYPE
> *` argument, so "importance" is the only remaining sorting criteria, hence
> (libctx, propq) are always the most important and should go to the
> beginning of the args list (with the exception of the `self/this` kind of
> argument that always goes first)?
>

That's a reasonable way to express things.

The actual underlying point I am making is that we should have a rule in
place that is documented and that works within the programming language we
are using and that over time doesn't turn into a mess.
We do add parameters (in new function names) and we do like to keep the
order of the old function - and ending up with a pile of things in the
"middle" is in my view is one of the messes that we should be avoiding.

I think the importance argument is the one that helps for setting order and
on your "required args" coming first approach the importance argument also
applies because it is actually a required argument simply with an implied
default - which again puts it not at the end of the argument list. The
library context is required - always - there is just a default - and that
parameter must be present because we are working in C.

Whatever it is that we end up decided to do, the rule should be captured
and should also allow for the fact that we will evolve APIs and create _ex
versions and those two will also evolve and a general rule should be one
that doesn't result in an inconsistent treatment for argument order as we
add _ex versions.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200905/40d4b5de/attachment.html>