On Thu, 23 Jan 2020 at 18:34, Malte Skarupke via Boost <boost@lists.boost.org> wrote:
If I understood correctly, your new algorithm increases the requirement for Boost.Sort to C++17 from C++11. I don't see a good reason for doing that. You can replace if constexpr and the generic lambdas in your implementation with other code constructs that work on C++11.
It only requires C++17 if you want to use ska_sort. The other algorithms remain at C++11. I agree that this is a little unfortunate, but when I briefly tried to get rid of "if constexpr" in the code, it turned out to be a giant pain. It would also probably make the code compile much more slowly. If you are trying to sort nested types, like vector<vector<pair<string, int>>>, compile time can explode without some of the short circuiting that I'm doing using if constexpr. (I can explain why it explodes if you're interested, but for now I'll just say that it works different from comparison based sorting and you have to instantiate new code at every level of depth) I know I can do the same short circuiting without if constexpr if I put in enough work, but I think the code quality would suffer a lot, making the code much harder to read and maintain. (not that it's simple as is, but it would go from "hard to read" to "impossible to read")
My experience with looking at C++17 codebases (which are still quite limited) suggests that generalized use of "if constexpr" is a code smell that suggests bad design, making code difficult to maintain and extend and also causing unnecessarily long compilation times. Designing generic components and combining them in a more traditional fashion leads to more sharing of template instantiations as special-casing happen at the declaration boundary rather than in the middle of a definition. If constexpr also encourages placing local specializations at random points in the generic code instead of looking at the big picture, rationalizing requirements and deferring any special action to a policy that models a more or less refined concept, which definition is in a single place within the code. Local changes will eventually pile up, and since they probably have some relation to each other but are not together in the code, they end up being fragile. I haven't looked at your code in particular, but that might be something to consider.