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

[Peter Kasting]

On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen <ggaren at apple.com> wrote:

> Perhaps we could at least encourage const-correctness for newly-written
> classes? By this I mean both adherence to the logical-constness rules you
> stated earlier as well as not adding non-const accessors and members unless
> needed -- otherwise it's easy to just err on the side of never using const
> anywhere.
>
>
> I'm still not convinced that it's meaningful to talk about a "const-correct
> class". The const that you put on a member function only has meaning when
> somebody uses a const pointer or reference to your class. More importantly,
> any design issues raised or bugs caught by const only get tested when
> somebody uses a const pointer or reference to your class.
>
> So, the key to const-correctness is deciding when to use const pointers and
> const references -- once you're using a const pointer or reference, the
> compiler will tell you which member functions need to be const.
>

Hmm.  Relying on compilers to check constness is inherently scary because
they check physical constness, which is neither a superset nor subset of
logical constness, which is what we want to be checking.

At least in my head, my design process is generally "the class should expose
as few APIs as possible, and they should be const wherever possible (without
violating logical constness)".  Obviously in some sense classes aren't built
in a vacuum and their external users determine the APIs they expose, but I
don't like the "constness is determined purely by external need" route
because it leads to problems like "the first user of this class wanted to
mutate everything, so I made no members const, and now I can't trivially add
a non-mutating const usage because it requires plumbing constness through
everywhere".

Maybe what I'm trying to say is that it's generally feasible to design with
"make usage patterns const where possible" in mind, but it's harder to
retrofit.  Or maybe I'm saying it's easier to make things non-const later
than to make them const.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110602/2f27eda0/attachment.html>