Why there is no concept of “const-correctness” for

Question

Use case:

class A {
  static int s_common;
public:
  static int getCommon () const { s_common; };
};

Typically this results in an error as:

error: static member function ‘static int A::getCommon()’ cannot have cv-qualifier

This is because constness applies only to the object pointed by this, which is not present in a static member function.

However had it been allowed, the static member function's "const"ness could have been easily related to the static data members.
Why is this feature is not present in C++; any logical reason behind it ?

Answer 1

cv-qualifiers affect the function's signature. So you could have:

class A {
  static int s_common;
public:
  static void getCommon () const {  };
  static void getCommon () {  };
};

Now... how would you call the const one? There's no const object to call it on (well, you could call it on a const object, but that's not the point).

I'm just guessing here, there probably are other reasons. :)

Answer 2

Good question.

I believe conceptually const-ness applies to well-defined object or a data structure. Not to global/static or etc.

The same way I may ask why a global (or alternatively namespace-specific) function may not be const, i.e. it may promise not to modify any global (or namespace-specific) variables.

This doesn't make too much sense IMHO. But yes, const-ness of static members belonging to a specific class - this might be useful in some cases IMHO.

Answer 3

A function that doesn't change any global state is pure. C++11 introduces attributes that might include [[pure]] on particular platforms.

One problem with const is that it's part of the type of the function. Assigning that static const function to a "normal" function pointer would require a special conversion, cast, or decay rule. And as Luchian mentions, it would allow completely ambiguous overloading.

Essentially you are describing forming a singleton object from the static members, sharing a common, qualified indirect access path. For the non-const object to appear const, it must be accessed through something, but there's no this. Would its decltype change? There is no good answer. If you want all this, then put them explicitly inside a class object.

Answer 4

My guess is that using static and const on a member function to refer to constness of static member variables was simply never considered as an option. IMO your suggestion is kind of a strange (but maybe sensible) way of mixing those two keywords.

Answer 5

The rationale for having const cv-qualifier on member functions is:
To indicate that the hidden pointer this being passed to the member function is immutable and it cannot be modified. A static member function does not have the hidden this parameter, and hence const for static member functions is meaningless.

However had it been allowed, the static member function's "const"ness could have been easily related to the static data members.

That was not the rationale for having const qualifier to begin with, this is evident from the fact that you cannot have cv-qualifiers applied to a free function. The cv-qualifiers were and are only meant for this, the object whose function is being called.

Answer 6

However had it been allowed, the static member function's "const"ness could have been easily related to the static data members.

This is where your question becomes confused. A non-static member function declared as const still has non-const access to static data members. The const only applies to this (ie: the non-static data members).

It would make no sense for a static member function to use const in the same way syntactically, yet have a completely different outcome (ie: making access to static data members const).

Furthermore, static data members are nothing more than class-scoped global variables that have class access controls (public/private/etc) on them. So it doesn't make sense for some functions to have different const access to them, especially based on their signature.