Jim Bosch reviewed Section 3 of the C++ Standard. He noted this change which I felt warranted SAT clarification:

3-9: This is a confusing conflation of two entirely different concepts: it seems to discourage all global variables, regardless of whether they're in a namespace, but only to discourage free functions when they aren't in namespace. If that reading is correct, I think both are sensible recommendations, but they need to be clarified, and probably split up. If the reading should be that all free functions are discouraged, that'd be a terrible rule we violate all over the place. If the reading should be that global variables are only discouraged when not in a namespace, that needs to be clarified (and IMO it could be bumped up to a complete prohibition).

Refer to: https://confluence.lsstcorp.org/pages/viewpage.action?pageId=16908685 Rule 3.9. The current Rule states:

3-9. Global variables and functions SHOULD be avoided and if used MUST always be referred to using the '::' operator.

::mainWindow.open(), ::applicationContext.getName(), ::erf(1.0)

In general, the use of global variables should be avoided. Consider using singleton objects instead. Only use where required (i.e. reusing a framework that requires it.) See Rule 5-7 ( .https://confluence.lsstcorp.org/pages/viewpage.action?pageId=16908706#C++Statements-5-7 ).

Global functions in the root namespace that are defined by standard libraries can often be avoided by using the C++ versions of the include files (e.g. #include <cmath> instead of #include <math.h>). Since the C++ include files place functions in the std namespace, using namespace std;, which is permitted by Rule 5-41, will allow these functions to be called without using the :: operator. In cases where functions are only available in the C include files, the :: operator must be used to call them. This requirement is intended to highlight that these functions are in the root namespace and are different from class methods or other namespaced free functions.