... that are numbers

This is not enough imo. The description should be more explicit about what it allows (or disallows). For example, char is explicitly excluded, but most solutions (including mine) also count any non-char integral type like bool and char32_t, which aren't tested. Moreover, if an answer only hardcodes double and int, are they not excluding other valid numeral types like std::size_t or long? I'm not saying these types should be tested at all - but the description should upfront be clear that it is only testing int and double. It signals that the solver should not strive for total correctness, and should instead make assumptions. Sounds like overthinking, but solvers can't see the submission tests and so can't tell what assumptions are being implicitly made.

Regular sizeof should be exempt from the restrictions. You can use it as a part of a valid answer. Only sizeof... should be disabled.

in test example 3.14 and 42 are equal to 45.14, this is clear, but i wonder where did 0.001 come from?

Awesome Kata! C++ tuples are insane to work with! Can you suggest me more Katas similar to yours?

https://www.codewars.com/kata/reviews/5883785e512b0330ff0003c9/groups/64f00dae18408b0001497ac8

https://www.codewars.com/kata/reviews/58847cf4a3dd74693e000114/groups/64f00d7318408b0001497abf

The tests are not adequate.

These additional things should also be tested:

• Custom containers that only implements std::find (only std::vector and std::set is being tested)
• Containers that has both .find and std::find (the former should be used instead of latter)

Tests should be added against this: https://www.codewars.com/kata/reviews/58617cfcc129d2e704000dbc/groups/5acd32cec7309c65cb0038f5

This solution should be blocked as well, it's bypassing the sizeof check.

This solution shouldn't pass, but it currently passes (sometimes, since it takes almost 12s to run), which means test case sizes need to be increased.

Raising an issue here as this kata shares a problem with its sibling.

The transform and filter katas are really nice, figuring out all the stuff required to implement a proper generic C++ iterator and please the type system was really interesting and challenging. But at the same time it's really bad that you authored 2 separate katas on the same topic. The solution to both of them is almost identical, the changes required to convert map to filter (or vice-versa) are trivial, and as soon as one kata gets approved, the other will instantly turn into a duplicate. You should either rework them into one asking to implement both map and filter, or simply unpublish one of the katas, as they will not survive together.

There should also be small random tests.