Re: const correctness

On Wed, Nov 9, 2011 at 10:45 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>  Perhaps there should be a few more 'XXX_const' accessor function
>>> variants, for example list_nth_const,
>>
>> This is exactly what was bothering Robert and me about Peter's
>> patch.If you go down this road you soon start needing duplicate
>> functions for no other reason than that one takes/returns "const"
>> and one doesn't.
>
> What about existing functions which are not intended to modify their
> inputs, don't actually do so, and can be marked to indicate that
> just by adding "const" to the current declarations?  Aside from any
> possible value in code optimization by the compiler, I find it helps
> me understand unfamiliar code more quickly, by making the contract
> of the API more explicit in the declaration.  Perhaps it's worth
> going after the low-hanging fruit?

My feeling is that there's no harm (and possibly some benefit) in
const-ifying functions that do very simple things. But as soon as you
get to functions where the const-ness starts growing all over the
system like kudzu, it's time to run away screaming. Moreover, I don't
really want to see us spend a lot of time figuring out exactly what we
can or can't const-ify. I feel as virtuous as the next guy when I
mark something const, but my experience over the years is that it
rapidly turns a huge amount of work. That by itself is not enough
reason not to do it; many worthwhile things are hard. The kicker is
that it's a lot of work for an unbelievably tiny benefit, sometimes a
negative benefit.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company