> If "everything should be const unless it has to be mutable" is a reasonable position to take For a language like C++ I don't think that's a reasonable positi

> If "everything should be const unless it has to be mutable" is a reasonable position to take For a language like C++ I don't think that's a reasonable position. "Good" class design is about a class encapsulating some behavior and providing methods to access that behavior. Any "interesting" behavior is based on mutable state, whereas const methods are useful only as observers of the state. So "const" as default would make the code more cluttered... Heck, Java and C# don't even have const (though recent version of C# have added kind-of struct constness...) > sure, but that's also a workaround for something that would be nice if it were clear just by looking. In any sufficiently large program, nothing is clear just by looking. Such "local artifacts@ (like, explicit address-of operator) are irrelevant, the fewer the better. Writing `unique_lock<mutex> lk(&my_mutex)` would not add the tiniest bit of clarity compared to what you write now `unique_lock<mutex> lk(my_mutex)` > Is the function taking the arg by mutable reference because Dave forgot? That's easy to check: change it to const and see whether the method still compiles. > Documentation in the header, popped up by your ide/text editor? In the end, you always have to go to the function's definition and inspect it, and possibly follow the call chain further to find out what's really happening (i.e., the top-level call site is no longer relevant), and that's where IDEs shine. And no amount of syntax changes is going to save you from a const reference being aliased by a non-const one.