Why does operator ++ return a non-const value?

Question

I have read Effective C++ 3rd Edition written by Scott Meyers.

Item 3 of the book, "Use const whenever possible", says if we want to prevent rvalues from being assigned to function's return value accidentally, the return type should be const.

For example, the increment function for iterator:

const iterator iterator::operator++(int) {     ... } 

Then, some accidents is prevented.

iterator it;   // error in the following, same as primitive pointer // I wanted to compare iterators if (it++ = iterator()) {   ... } 

However, iterators such as std::vector::iterator in GCC don't return const values.

vector<int> v; v.begin()++ = v.begin();   // pass compiler check 

Are there some reasons for this?

Answer 1

I'm pretty sure that this is because it would play havoc with rvalue references and any sort of decltype. Even though these features were not in C++03, they have been known to be coming.

More importantly, I don't believe that any Standard function returns const rvalues, it's probably something that wasn't considered until after the Standard was published. In addition, const rvalues are generally not considered to be the Right Thing To Do™. Not all uses of non-const member functions are invalid, and returning const rvalues is blanketly preventing them.

For example,

auto it = ++vec.begin(); 

is perfectly valid, and indeed, valid semantics, if not exactly desirable. Consider my class that offers method chains.

class ILikeMethodChains { public:     int i;     ILikeMethodChains& SetSomeInt(int param) {         i = param;         return *this;     } }; ILikeMethodChains func() { ... } ILikeMethodChains var = func().SetSomeInt(1); 

Should that be disallowed just because maybe, sometimes, we might call a function that doesn't make sense? No, of course not. Or how about "swaptimization"?

std::string func() { return "Hello World!"; } std::string s; func().swap(s); 

This would be illegal if func() produced a const expression - but it's perfectly valid and indeed, assuming that std::string's implementation does not allocate any memory in the default constructor, both fast and legible/readable.

What you should realize is that the C++03 rvalue/lvalue rules frankly just don't make sense. They are, effectively, only part-baked, and the minimum required to disallow some blatant wrongs whilst allowing some possible rights. The C++0x rvalue rules are much saner and much more complete.

Answer 2

If it is non-const, I expect *(++it) to give me mutable access to the thing it represents.

However, dereferencing a const iterator yields only non-mutable access to the thing it represents. [edit: no, this is wrong too. I really give up now!]

This is the only reason I can think of.

As you rightly point out, the following is ill-formed because ++ on a primitive yields an rvalue (which can't be on the LHS):

int* p = 0; (p++)++; 

So there does seem to be something of an inconsistency in the language here.