On 25 August 2024 21:29:45 BST, John Bafford <jbaff...@zort.net> wrote:
>This is only by current convention. It used to be that parameter names were
>not part of the API contract, but now with named parameters, they are.
Indeed, and it remains highly controversial among library authors, and is even
used as a justification for this RFC.
> There's no reason default values couldn't (or shouldn't) become part of the
> API contract in the same way.
I agree that they *could*, but I am making the case that they *should not*. The
ability to specify an optional parameter which is subject to change is a very
useful one, frequently used. If a library author *wants* to expose the default
value for manipulation by users, they can make it available as a constant, as
with e.g. PASSWORD_DEFAULT.
I can definitely see the use in features that enhance the existing use of
default parameters to mean "I trust the implementation to do the right thing,
and am not interested in specifying this parameter". (And see my earlier post
on how bit flags can still fit it into this meaning.)
None of the examples so far have persuaded me that there is sufficient value in
extending that to "every optional parameter also acts a public constant that
the caller can read out and act on at will".
Rowan Tommins
[IMSoP]
