Cppcoreguidelines: Clarification of I.24: Avoid adjacent unrelated parameters of the same type

[vingeldal]

What does "unrelated" mean exactly in this context?
I think the rule needs a clarification of how related/unrelated adjacent parameters differ.
I would be happy to make a pull request with a clarification myself but I have no idea what is meant.

[scraimer]

I agree that "unrelated" is confusing. The neither the word "related" nor "unrelated" appear in the body of the rule.

Remove it?

[shaneasd]

There are use cases though where it doesn't matter if you get the parameters confused. Consider a clamp function

int ClampToBounds(int val, int a, int b)
{
   return a < b ? std::clamp(val, a, b) ? std::clamp(val, b, a);
}

By design you can specify the bounds parameters in either order. Perhaps unrelated is a poor choice of words but I think this is the sort of use case that it's trying to permit.

I think the higher level rule is really "Don't have two adjacent parameters which a caller could pass arguments to in either order without being warned by the compiler, if either order would not match the authors intent". There's a lot to unpack there though...

[ChrisGuzak]

a several bools is also an error prone case.

[hsutter]

Editors call: Yes, the rule has an exception for examples like max, which is like clamp.

We will change the Guideline title to "Avoid adjacent parameters of the same type when changing the argument order would change meaning". Thanks!