> Secondly, if you don’t do this, future developers will keep adding parameters in an ad-hoc manner
You seem to presume a situation where you have absolute control over the initial signature of functions added to the codebase but no ability to constrain future changes.
1. All parameters that for which a default makes sense should be optional and have a sensible default.
2. (In languages where this is an option) All parameters with a default must be keyword-only.
3. All new parameters to an existing function (from a stable release) must have a sensible default.
> When you are building a re-usable framework, it’s silly NOT to anticipate future needs. The whole point of a framework is future needs.
The point of a framework is to avoid solving the same problem multiple times in each new project. If you haven't needed to solve it twice in two separate projects, be skeptical that you need it in a framework. If you haven't needed it once, don't even consider it. Code for problems you don't have is pure waste.
Much of the advice you offer is going to produce waste because YAGNI; each time they come up the cost may be small, but in aggregate it's going to be a lot of extra zero-value code being written and maintained, bloating development and maintenance costs and timelines. Occasionally, you'll be benefit a little down the line from hitting a problem you correctly anticipated, but often you’ll suffer from having not having anticipated the real constraints of the problem when dealing with it when it wasn't a real need, meaning you’ll have to throw away your just-in-case code anyway, and all the time you'll be dealing with extra complexity dealing with problems you haven't had any real need to address but only imagined might come up in the future.
You seem to presume a situation where you have absolute control over the initial signature of functions added to the codebase but no ability to constrain future changes.
1. All parameters that for which a default makes sense should be optional and have a sensible default.
2. (In languages where this is an option) All parameters with a default must be keyword-only.
3. All new parameters to an existing function (from a stable release) must have a sensible default.
> When you are building a re-usable framework, it’s silly NOT to anticipate future needs. The whole point of a framework is future needs.
The point of a framework is to avoid solving the same problem multiple times in each new project. If you haven't needed to solve it twice in two separate projects, be skeptical that you need it in a framework. If you haven't needed it once, don't even consider it. Code for problems you don't have is pure waste.
Much of the advice you offer is going to produce waste because YAGNI; each time they come up the cost may be small, but in aggregate it's going to be a lot of extra zero-value code being written and maintained, bloating development and maintenance costs and timelines. Occasionally, you'll be benefit a little down the line from hitting a problem you correctly anticipated, but often you’ll suffer from having not having anticipated the real constraints of the problem when dealing with it when it wasn't a real need, meaning you’ll have to throw away your just-in-case code anyway, and all the time you'll be dealing with extra complexity dealing with problems you haven't had any real need to address but only imagined might come up in the future.