Careless use of StringMaker can easily lead to ODR violations

[textshell]

When adding new specializations of StringMaker in a program it's fairly natural to start adding them in a specific compilation unit to get started. If the class is used in any other compilation unit where catch stringifies a value of that type this is a ODR violation which is one of our beloved "no diagnostics required" gotchas in c++. The result is that the use of StringMaker fails to work most of the time when adding it to existing projects without a central place for such things.

Ideally catch would find a way to make this kind of usage not a ODR violation. Maybe something is possible with use of "static" and/or anonymous namespaces. Or maybe it's not possible or too costly.

In the meantime it might be nice to add a "troubleshooting" section in the documentation to remind users that all compilation units that let a specific type come anywhere close to catch need to have exactly the same StringMaker specialization for that type.

[jayeshbadwaik]

The correct solution would be to never have a specialization only in one TU. All specializations should exist in all TUs identically. Otherwise, it is always an ODR violation, irrespective of whether it's detected or not. (Unless you use static)

[timblechmann]

template specializations do not compose well in this case. it would be great to have a more robust stringification mechanism, but from the top of my head i don't see any using some form of internal linkage.

it may be great to have a 'caveat' section in the documentation, though