N3160 is a proposal to add -- wait for it! --
min and max functions to C.
In principle? I agree. In practice?
NOMINMAX is defined almost everywhere FOR A REASON.
"Using a library version-test macro can help with backwards compatible code."
Good thing we added __STDC_VERSION_STDLIB_H__ in the standard recently, so we can test #if __STDC_VERSION_STDLIB_H__ > 202311L.
But it should be in its own header, yeah.
after you're done being sad/mad/whatever, it is your duty to help. So, I sent some mail:
I wanted to provide some early feedback on your paper, so as to give you the best chance of success should you pursue its inclusion into C2y/C3a (whatever the next version of C will be). I do hope that you will, and that this feedback will be useful.
As you may not be aware, "min" and "max" are popular and deeply contentious names in the C (and C++) global namespace. Microsoft wrecked a lot of people's day by providing "min(...)" and "max(...)" macros in C, causing a lot of problems for the last 30 years: https://stackoverflow.com/questions/11544073/how-do-i-deal-with-the-max-macro-in-windows-h-colliding-with-max-in-std
As you want these functions to appear in <stdlib.h>, a preexisting header, code that upgrades to C ${VersionNext} will suddenly start having collisions (even if it's not a macro) with typedefs, other functions, and maybe even other macro definitions. You can imagine that, for a language where we very often go out of our way to try to keep old code compiling as much as possible (even under dubious circumstances like Undefined Behavior), this can be quite a bad sting for users. There are also existing uses of "llmin" and other prefixed names which might make it harder to have these things exist (e.g., there is already a company that namespaces their functions with "ll" as it's their company's initials).
Asides from naming, there are some coverage (types used) and usage (mixed signed/unsigned) integer issues that could result from the use of these functions. I would implore you to, potentially, explore creating generic macros for each of these versions of the names
#define min(__left, __right) // ...
#define max(__left, __right) // ...and building an implementation that handles different sizes/signedness for two different integer types on the left and right hand side. When you do that, include the implementation in the paper as proof that this can be done. This will also bolster your proposal's standing, as it will easily demonstrate how subtle and difficult it can be to get it right. As for the number of types, the <stdbit.h> functionality shows generally some suffixes for types, and how many different types you may need to handle. This should help get out out of the naming struggle that exists for C (by using the suffixes, or by using both stdc_ and the suffixes).
I hope this helps. Let me know if you need someone to champion the proposal, or if you need to know the steps to get set up to attend a meeting yourself. (Don't bother attending the next one in October/November; we're not going to be able to review new material until the January 2024 meeting).
Best Wishes and Good Luck,
