On Tue, Jun 11, 2024 at 6:15 PM Aeren via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> 2. The example I gave applies to any setting that can be abstracted into that form, and it looked general enough that whenever you're dealing with optimization over multivariate functions, I thought that this proposal can be very useful. I'm not sure how adding "competitive programming" changes anything. Would it be better if I instead wrote "I found this abstractization in my production code"?
Did you?
Changes to the standard should be motivated by a desire to help
working programmers do their jobs better. They shouldn't be motivated
by people playing around with the language. People can do that, but
the language shouldn't change just to help them. As such, citing
"competitive programming" examples is not a *convincing* way to get
other people to think that this is a problem that needs solving.
Because from what I've seen, competitive programming problems often seem to be written to be challenging *for the sake of it*. To make you think.
Presumably, if std::set::partition_point got added and became the obvious go-to solution for this type of competition problem, that type of problem becomes too easy and won't be set. Because the solution is "just call a standard library function", which is not challenging. So now the only use case you presented, competitive programming, is no longer a use case. And we would have something in the standard that nobody is going to use.