[clang-tidy] False positive readability-make-member-function-const when const overload already exists

[chrchr-github]

#include <memory>

struct S {
    std::unique_ptr<int> u;
    int* get() { return u.get(); }
    const int* get() const { return u.get(); }
};

[<source>:5:10: warning: method 'get' can be made const [readability-make-member-function-const]]
    5 |     int* get() { return u.get(); }
      |          ^
      |                const

https://godbolt.org/z/sdKPco6Mn

[llvmbot]

@llvm/issue-subscribers-clang-tidy

[firewave]

Not sure that is an actual false positive as it is "technically" correct. That's a "pitfall" of std::shared_ptr::get() is a const function that hands out an pointer to the underlying object thus somewhat undermining constness (see https://en.cppreference.com/w/cpp/memory/shared_ptr/get).

IIRC there's no container/wrapper in the standard that allows you to store a pointer/reference and somewhat preserve the (let's call it) "physical constness" in case it is used as a member - there's always just the "technical constness". Hence why I tried to implement such a wrapper in danmar/cppcheck#4785.

But don't take my opinion as something to decide on. Someone with more insight/experience definitely needs to chime in on this.

[carlosgalvezp]

IIRC there's no container/wrapper in the standard that allows you to store a pointer/reference and somewhat preserve the (let's call it) "physical constness"

Still in experimental but there's https://en.cppreference.com/w/cpp/experimental/propagate_const

[firewave]

Still in experimental but there's https://en.cppreference.com/w/cpp/experimental/propagate_const

Thanks! That looks eerily familiar.😁

[chrchr-github]

The problem is not limited to std::unique_ptr::get():

struct S {
    int* p;
    int* get() { return p; }
    const int* get() const { return p; }
};

The warning is just not actionable in this case, and there are good reasons to have those two overloads.