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.
Of course if it's useful in real code outside of "hard for the sake of making you solve the problem" then it _would_ get used, and so might be worth adding to the standard. Which is why we're going to give more weight to real world use cases, not speed running algorithmic puzzles.
Also, as a std::lib maintainer, I am at the sharp end of "I want to win competitions but I want somebody else to implement the actual code and ship it in a standard library". So I want *extra* persuasion that this is actually useful.