Hi,
I also believe, that it'd be better to supply operator const value() than operator value() - this conversion is implicit so the const version would be safer.
Why bother with the "const"? The usage will already return a r-value, i.e. a temporary. The kinds of mutable operations that can be done on it are already restricted. The only times I've seen mutable operations on such values are ones that were deliberately done. The "const" adds nothing but annoyance; the safety-conscious won't need it since they wouldn't try mutable code, and the programmers that want to abuse a mutable operation would be upset that you locked them out. It's the same kind of controversy about (member) functions returning non-reference objects with "const" attached. (And we seen "cute" tricks in C++ made for our "benefit" back-fire later, like std::vector<bool>.)
-- Daryle Walker
Probably you're right, I wasn't thinking it over very much because in the current implementation I'm working on the conversion operator returns const value_type & (because it must also support UDTs, that might be inefficient to return by value) so there's no question whether const is needed or not, it must be there. The reason I was thinking so was "Exceptional C++" item 20 p.9 which says that postincrement operator should return a const value, from this I deduced that conversion operator should also. But as I mentioned, I didn't think of it a lot so I may be wrong ;-). Best regards, Robert