glibc does exactly this for bsearch. The difference with C++ is that the specialized function (bsearch or qsort) does not receive vague linkage, so it is not go

glibc does exactly this for bsearch. The difference with C++ is that the specialized function (bsearch or qsort) does not receive vague linkage, so it is not going to be deduplicated by the link editor. For bsearch, the code size increase is probably not a problem, but qsort tends to be much larger. Basically, intra-procedural constant propagation plus inlining into qsort is very beneficial, but inlining the specialized qsort itself is probably not such a great idea. Presumably LTO with profile feedback could help here, but striking the right balance is going to be difficult (as is with C++, which tends towards code duplication, despite vague linkage and link editors that perform identical code folding). I'm not sure if specialization is a good argument for generics. Not everyone implements generics through full specialization/monomorphization, and then the performance benefits are not much more likely to emerge than with function pointers or vtables. And many JIT compilers can effectively specialize code involving indirect calls.