I don't think this is enough for a lot of common cases. Let's say you want to write a 'sort()' function. It takes a 'vector' and a comparator function. Unless that comparator function is declared 'const', you can't be sure that it won't destroy your 'vector'.
Another example. Let's say your 'foo()' function calls 'bar.toString()'. How can the compiler tell whether this call should be allowed when 'bar' is 'const'? You would need to know whether 'toString()' modifies 'bar' or not, but you don't have a way to tell. You might be able to figure this out if you look inside the code of 'toString()', but what if 'toString()' is virtual? You can't look at the code then.
I would argue that automatic inference of 'const' is a very bad idea because it defeats the whole purpose of having 'const' in the first place -- to catch bugs at compile time. If somebody modifies 'find()' in a way that makes it non-const, then your code will continue compiling without errors. However, if somebody relies on the fact that 'count()' is const, then that person would be royally screwed, and it will take weeks to find the bug.
Thanks for the summary. This is my code. I've since switched to using "Bst" instead of "BST" for class names. I've also stopped putting spaces inside parentheses and angle brackets. Although I still think that code looks better with the spaces, I realize that most people don't format it that way, and I'm fine going with the popular convention.
This really sucks for angle brackets though. Compare
Another example. Let's say your 'foo()' function calls 'bar.toString()'. How can the compiler tell whether this call should be allowed when 'bar' is 'const'? You would need to know whether 'toString()' modifies 'bar' or not, but you don't have a way to tell. You might be able to figure this out if you look inside the code of 'toString()', but what if 'toString()' is virtual? You can't look at the code then.