On Sun, Oct 28, 2012 at 11:16 PM, Maciej Stachowiak <m...@apple.com> wrote:
> On Oct 28, 2012, at 10:09 PM, Peter Kasting <pkast...@chromium.org> wrote: > > On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak <m...@apple.com> wrote: > >> I am not sure a blanket rule is correct. If the Foo* is logically related >> to the object with the foo() method and effectively would give access to >> mutable internal state, then what you say is definitely correct. But if the >> const object is a mere container that happens to hold pointers, there's no >> particular reason it should turn them into const pointers. For example, it >> is fine for const methods of HashSet or Vector to return non-const pointers >> if that happens to be the template parameter type. In such cases, constness >> of the container should only prevent you from mutating the container >> itself, not from mutating anything held in the container, or else const >> containers of non-const pointers (or non-const types in general) would be >> useless. >> > > IMO const containers that vend non-const pointers _are_ nearly useless. > > I consider logical constness to include not only "this statement has no > observable side effect" but also "this statement does not allow me to issue > a subsequent statement with observable side effects". > > > Surely that's not quite correct as a definition of logical constness. You > can always pass a const reference to another object's setter to cause an > observable side effect. The scope of side effects under consideration has > to be limited to the object itself plus anything else that could be > considered part of its state. In brief, a const method on object O should > neither mutate O nor expose the possibility of mutating the state of O, but > it has no responsibility for its involvement in mutation of objets > Sorry, I left out words. Consider the phrase "on the state of the object" to be appended to both those quoted phrases I originally said. I still think that it's extremely difficult to avoid "exposing the possibility of mutating the state of O" in most cases. The mechanism may be obscure, but it is frequently present -- frequently enough to make me advocate for hard-and-fast rules. Consider the following use case: > > - I have collected a an ordered list of pointers to objects of type T in a > Vector. > - I'd like to call a function that will operate on this list - it's > allowed to do anything it wants to the Ts, including mutating them, but it > can't alter the order or contents of the Vector. > (For example, I may want to pass the same list to another function). > > Currently one would express this by passing a const Vector<T*>&. I don't > see a good approach to this that strictly follows the suggested rule. You'd > have to either copy the Vector to a temporary just for the call, or abandon > const-correctness. > I think by "abandon const-correctness" you mean "pass a Vector<T*>*", which is indeed the route I'd go. I don't consider that an abandonment of const-correctness, in that you are indeed not violating logical constness. But yes, you lose the ability to convey the idea that "this function, in and of itself, doesn't modify the number or order of elements in the vector". On the other hand, you don't put yourself in a position where a caller of the function could then immediately use his returned T* to mutate the vector -- which is often a real possibility in real-world systems. There aren't any magic bullets here. Given that the compiler can very rarely use "const" to optimize anything anyway, const is effectively whatever we want it to be. I prefer hard guarantees that occur less frequently to less-ironclad guarantees that are more common. Reasonable people can disagree. I think your position -- that the hard guarantee usually makes sense for non-simple-containers but you'd prefer to allow a less-strict usage for simple containers -- is one that has some appeal even if it's not what I'd personally choose (and is more complex to explain/enforce). I certainly think we'd be in a better world if the codebase followed this policy, compared to today. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
