[webkit-dev] On returning mutable pointers from const methods

[Filip Pizlo]

It is useful to say that "getting a pointer to T from an object of type S does not change S's state".

-F



On Oct 28, 2012, at 2:09 PM, Peter Kasting <pkasting at chromium.org> wrote:

> On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak <mjs at 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".  A const Vector that allows to to obtain a non-const element pointer, which you subsequently mutate, means that you can mutate the vector.  (Consider for example an element destructor that removes the element from the vector.)
> 
> If you allow const methods to return non-const pointers, it's almost always possible to construct some chain of events that leads to mutation of the const object or of state it can observe.  It is far easier to simply make simple rules like "const methods shall not vend non-const pointers" than try to allow it but guarantee that all the code everyone writes is safe.
> 
> PK
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121028/efc45325/attachment.html>