C++Now 2021

Making functions that can be called just the right way is trickier than it sounds.
It is way too easy to simply use only the built-in and some of the cornerstone STL types as parameters to the function.
People commonly go about taking ints, and bools, and doubles, and strings.
What actual semantics are tied to individual parameters are usually expressed through the name of the variable, or worse, only in the documentation.
Special tools outside of the language's jurisdiction are needed to handle these names.
And we all know people rarely like to read the documentation...

However, the situation is even worse than it would seem at face value: given a function like "drawBlameView(FileID, int, int, bool, DrawMode)" you would think only the two ints are the problem...
Wrong! All 5 parameters here might be mixed up, due to typedefs hiding FileID to be actually int, and the implicit conversion between bool and the rest.
Unfortunately, this is not immediately apparent, especially when a new person joins an existing project, and the responsibility falls to all of us to make sure our function interfaces are safer.

Several tools exist that try string magic to figure out whether a call is done with badly ordered arguments by mistake.
However, those tools mostly can only help after the fact.
We will discuss how one can go about finding and filtering out the functions in their project.
What's more, a highlight and plea for preventive refactoring also help in identifying places in the code where type safety will not only help function calls but other parts too, such as your local variables.
The method might sound simple at first, but there are plenty nasty creatures lurking in the shadows... especially if you want to do all this for an incredibly huge project that has never evolved to proper type safety.