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

[Peter Kasting]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121028/4afc6bde/attachment.html>