On 25 August 2024 21:29:45 BST, John Bafford <[email protected]> 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]