Minor C++ Fork to allow the assertion software to log out std::pair (matters for the fixed tests). Without it, the fixed tests still work as expected, but the log messages are unhelpful ([unsupported type]) (the assertion software CW uses requires boilerplate to know how to log out standard library types). I prematurely removed this snippet once I switched to the no-ref-sol approach, forgetting that the fixed tests still do the typical assert-equals stuff. Added it back. (Also, made the initial solution return [] instead of [[0, 0]]`, to reduce clutter)

C++ Translation

C++ Translation. (Omits the reference solution, per the new JS fork)

Approved

LGTM! I would've personally loved to see generateTestCase further simplified as below, but it's good as-is

std::vector<int> result(randint(15, 100));
std::iota(result.begin(), result.end(), randint(-1e6, 1e6));

if (not isConsecutive) {
    const std::size_t index      = randint(1, result.size() - 2);
    const std::size_t eraseCount = randint(1, result.size() - 1 - index);
    result.erase(result.begin() + index, result.begin() + index + erase_count);
}

return { result, solution(result) };

• I heavily encourage you to add the Python fixed tests, splitting them into an It(all_consecutive) and It(non_consecutive). The two tests from JS are too little imo

• From the description:

  The numbers will also all be unique and in ascending order

  This means std::generate(result.begin(), result.end(), [&] { return randint(-1e6, 1e6); } ); is non-compliant since it can generate duplicates and is not guaranteed to be sorted

• Optioal, but fmt::format("numbers = {{{}}}\n", fmt::join(numbers, ", ")) is unnecessary because fmt::format("numbers = {}\n", numbers) will output the same exact thing

Yeah that's fair, but I hope OP reconsiders including that part. Omitting it is better for clarity, and is more language-agnostic if this kata ever gets translated to languages where unsigned integers are the idiomatic encodings for indices (so a negative index isn't even possible)

All elements are guaranteed to be non-negative integers.

An index is considered out of bounds if it is less than 0 (...)

Where would an index < 0 come from, given this guarantee?

The solutions under here aren't being pushed into a company's repository. Sometimes, best practices advice like this is unsolicited

Oh wow

It need not be a consideration, yes, but in this case the discussion is about whether or not the task should be changed. If a change is objectively beneficial, then the effort to set it up should be irrelevant. But since I can't really see a gain of ditching unit application, I think it then becomes fair to bring up possible hurdles

No, it's not that simple in C++ for many reasons. I mean I'd get into it in depth if you want to, but I don't think it'd be worthwhile unless someone else who's well aware of these hurdles wants to chime in. If you want to get an idea of the types of challenges that can encounter someone trying to make random tests of this kata, you can take a glimpse at the C++ random tests. Again, these are testing-only challenges - the task is pretty straightforward to implenent in tons of ways from the solver's side. Again, this change is possible, but unless I'm wrong, it will require a new invoke_op function in the vein of the invoke_num function available in the tests. Again, would love if a C++ programmer can chime in.

I don't encourage changing to x(op(y)). Although it's a seemingly minor change, doing it like this would make random testing in C++ way more inconvenient. Long story short, some of the techniques lots of people use to solve this problem (but not all) can mean that y as an expression is ambiguous, because there could be multiple overloads of y, or multiple template instantiations of y, and as someone who's outside the solver's head, I can't make the informed decision to guess the signature of the correct overload (for example, what if they use some defaulted arguments I would have no idea about?). On the other hand, with x(op(y())), I never need to deal with the problems of y as an expression, because all I need to concern myself with is y(), which returns a guaranteed integer. I'm not saying adjusting the random tests for x(op(y)) is impossible - it's not - but it would require more hacking around the strict type system.

C++ Translation.

Although extremely rare, the random tests have a chance of producing incorrect expected values if the generated random substring happens to repeat itself (ex: bzbz, earear). The chances of this happening are super low, but seeing how the readability of the random tests in this kata is low, could this be a case where it would be more readable + foolproof to make use of a reference solution instead of trying to completely pregenerate the output?