02-06-2026, 07:14 AM
The wording of rule 6.5.2 seems to imply that any entity with internal linkage may not be declared static, even though the static keyword “also has other uses”.
With that interpretation, the rule would completely prohibit the use of static class members with internal linkage.
For example, given this code snippet:
In cases 1 and 2, the static keyword is “inappropriate”. F1 should be declared inside the anonymous namespace instead and for F2 the static keyword could be simply dropped.
F3 has internal linkage but the static is not used for linkage but to make the function a class function. Still, the amplification of rule 6.5.2 says that internal linkage of an entity is only appropriate if it’s not declared static, which F3 clearly is.
Is that intentional? Should the wording be improved to make it clear that only static declarations which could affect linkage are considered?
Or (to simplify static analysis) could an exception be added for static class members?
With that interpretation, the rule would completely prohibit the use of static class members with internal linkage.
For example, given this code snippet:
Code:
static void F1() {} // 1
namespace {
static void F2() {} // 2
class Klass {
public:
static void F3() {} // 3
};
} // namespaceIn cases 1 and 2, the static keyword is “inappropriate”. F1 should be declared inside the anonymous namespace instead and for F2 the static keyword could be simply dropped.
F3 has internal linkage but the static is not used for linkage but to make the function a class function. Still, the amplification of rule 6.5.2 says that internal linkage of an entity is only appropriate if it’s not declared static, which F3 clearly is.
Is that intentional? Should the wording be improved to make it clear that only static declarations which could affect linkage are considered?
Or (to simplify static analysis) could an exception be added for static class members?

