Re: [RFC] Default expression

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