"using namespace std" is usually fine when your working on small projects. However once you start working on more complex programs, your functions could conflict with the std functions, creating alot of unneeded issues. It's way better in the long run to type the extra 5 keys

Really? why not? it saves a lot of time.
Sorry I'm new to this.

Was captured by value. Nothing from the outside scope got mutated.

The guy is a time traveler

please feel free to fix it if you like.

Answer given in the other comments in the other flow: it is not a matter of 'execution policy' but a matter of the nature of the 'Input IT' in 'std::none_of'. Without using the ExecutionPolicy parameter, std::none_of uses 'LegacyInputIterator' (see https://en.cppreference.com/w/cpp/algorithm/all_any_none_of). In this context the 'LegacyInputIterator' CANNOT be decremented nor 'n-added'. Thus, parsing collection from begin() to end() by incrementing the iterator (meaning using '++it' only) is guaranteed. See https://en.cppreference.com/w/cpp/named_req/InputIterator

Actually IMHO it is not a matter of 'execution policy' but a matter of the nature of the 'Input IT' in 'std::none_of'.
Without using the ExecutionPolicy parameter, std::none_of uses 'LegacyInputIterator' (see https://en.cppreference.com/w/cpp/algorithm/all_any_none_of).
In this context the 'LegacyInputIterator' cannot be decremented nor 'n-added'. Thus, parsing collection from begin() to end() by incrementing the iterator (meaning using ++i only) is guaranteed.
See https://en.cppreference.com/w/cpp/named_req/InputIterator

Took me a while to understand... If you pass directly the 'par' struct in the std::none_of, actually there is a copy and when you return the current 'par' in the main function will always have a count at 0 (as by default)...

BTW... Sure you will like my last one...
Can you spot why we should use 'std::ref(par)' and not just 'par' ?

You may make it 'if then else' as well... Doesn't really matters and I understand your concern.
This one relies to a youtube video of 'The Cherno' reviewing code on rendering, std::any_of will make an early exit on the scan (if condition is met) while if we used std::accumulate, it would be nicer but it would always scan the entire range of values.

It has not been a problem for the few who passed the kata. Read the documentation for "SplitString" (System.StrUtils) or see "stackoverflow.com ... pascal-split-function".

It should be visible now.

as a general rule, dont pay attention to the Clever/Best Practices votes on Codewars, they are meaningless (it's mostly beginners who do not fully understand the code who vote; and early upvoted solutions tend to bubble up to and stay at the top of the page)

Yep, it will. And if you read the kata, that will always produce the result required by the kata.