[jhg]

With regards to the const part of the discussion -

Does anyone knows any research or even a state of affairs of const inference in language design?

The idea is similar to type inference whereby a compiler (or some other tool in a chain) would take care of understanding which arguments/variables/functions are going to be const and generate appropriate warnings based on that. For example,

  void foo(int * a) { (*a)++; }

  void bar(int * b) { foo(b); }

  void baz(const int * c) { bar(c); }

A compiler would generate a warning when baz function, because foo() includes a non-const operation on its argument, bar() is non-const for the same reason, and so it cannot be called for a const pointer.

[jpr]

I'm not sure what you mean, since current compilers already warn if you write that code.

[jhg]

Hmm, OK. Try a different example - the compiler should allow the following code without any warnings:

  void foo(int * a) { }

  void bar(int * b) { foo(b); }

  void baz(const int * c) { bar(c); }

Point being is that the compiler should warn of the const violation based on whether a function argument or a class member is getting touched in the function code.

In fact, the example above is more relevant, because what I am ultimately aiming for is to not need to make member functions const, and yet be able to call them for const class instances.