[webkit-dev] Do we have a style preference about const member functions?

[Maciej Stachowiak]

On May 31, 2011, at 5:55 PM, Brent Fulgham wrote:

> Hi,
> 
> On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> I agree that one useful distinction is whether a particular kind of object
>> is every manipulated via const pointers or references. If we never use const
>> references/pointers to a particular kind of object, then it is probably not
>> useful to maintain const-correctness discipline for that class.
> 
> I don't agree with this.  I see no harm in maintaining const
> correctness on objects, even if they are not currently manipulated
> through const references/pointers.  They provide clear,
> self-documenting evidence that the object design intends that certain
> methods do not visibly alter the object.
> 
> I fail to see how abandoning const correctness can do anything but
> cause us to start missing bugs that we would otherwise have found via
> compiler errors.


It's hard for me to evaluate this in the abstract. In general I like the compiler telling me as much as possible. But there's both false positive and false negative problems with const-correctness, and a maintenance burden besides just fixing the compiler errors.

For example, the compiler does not tell you that the following implementation of Node::previousSibling() (currently in our code!) is totally wrong from the "logical const" perspective:

    Node* previousSibling() const { return m_previous; }

The correct way to do const-correctness here would require more verbosity:

    const Node* previousSibling() const { return m_previous; }
    Node* previousSibling() { return m_previous; }

And the first variant would be dead code if we don't ever actually use const node pointers.

Given your views on const-correctness discipline, what do you think is the right way to handle this situation? Note that this pattern comes up for many core DOM methods and many render tree methods.

Regards,
Maciej