Do we really need const?

[Bill Baxter]

Robert Fraser wrote:
> Janice Caron Wrote:
> 
>> On 9/17/07, Jarrett Billingsley <kb3ctd2 at yahoo.com> wrote:
>>> "Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message
>>> news:fcl79k$18vu$1 at digitalmars.com...
>>>
>>>> It seems from the discussion here the past week, there is no real
>>>> multithreading benefit to be had from const/invariant.  'Pure' is where
>>>> it's at for that.  So maybe we're just better off without the complexities
>>>> of const.  I've certainly gotten used to the lack of const in Python, so
>>>> why not in a C++-ish language?
>>> I start to wonder how much of the "of COURSE we need const!" thinking comes
>>> from "if all you have is a hammer, everything starts looking like a nail."
>>> That is, I wonder how many people think we absolutely need const because
>>> they're so used to using it in C and C++.
>>>
>>> Never having learned a const-correct language (started with various BASICs,
>>> then on to very rudimentary C++, then D, and also a bit of Java and C#), I
>>> simply don't see the overwhelming need.  Sure, there are a very few cases
>>> where const could be useful in my code for efficiency's sake, but I've never
>>> felt like I was missing any expressive power.  Furthermore, I have been
>>> bitten exactly once by something that theoretically could have been
>>> prevented by const.  It took me two minutes in the debugger to track down
>>> the problem.  I'd say that those two minutes were a much better tradeoff
>>> than the god-knows-how-long it'd take to write const and non-const overloads
>>> of who-knows-how-many functions.
>> Let me share some real world experience about using const versus not
>> using const.
>>
>> Today, I found myself writing a small standalone project in D, for my
>> own personal use. I wrote a function that took a ubtye[] as it's
>> parameter. It occured to me that the function didn't actually modify
>> the array, so (since I have D2.0) I could have declared the parameter
>> const. I considered it, and then I thought: "Nah... let's not bother.
>> Too much effort".
>>
>> BUT...
>>
>> When working on a big project, it's a different story. A couple of
>> years back, I was team leader in a C++ project with half a dozen other
>> developers. It was a multithreaded application. So I wrote this bunch
>> of classes which had to be called in a certain way or it wouldn't
>> compile - because data had to be shared between server instances and
>> so forth. Well, a couple of the developers figured out the right thing
>> to do all by themselves, and that was great. Of the others, about
>> three tried the "obvious", discovered that it wouldn't compile because
>> of const-correctness, and came to me asking why not. I explained that
>> there was good reason for the constness, that it was thread-safety
>> issue, and then I told them the correct, "authorised" way of doing
>> things, and then they went off and did the right thing. So in this
>> case, const forced everyone to get it right. Well - almost everyone.
>> (There's always /one/!) One team member tried the "obvious",
>> discovered that it wouldn't compile, and then, instead of asking me
>> why not, figured out a workaround to make it compile using pointers.
>> (If C++ had had intransitive const, the compiler would have prevented
>> this, but it doesn't so he got away with it). Then ... weeks later ...
>> we found that the server randomly fell over after several hours of
>> problem-free up-time. The symptoms were random memory corruption. It
>> took us about a month to find and fix the problem! Care to guess what
>> the problem turned out to be? Yes, it was that errant team member's
>> workaround for const-correctness that ended up causing multiple
>> threads to (rarely) become thread-unsafe. (Moral: If your code won't
>> compile when you try to call a co-worker's function, don't hack up a
>> workaround - instead, ask them if you're calling it right!)
>>
>> So what I conclude from this is:
>>
>> (1) For a small project, you can ignore const. Just because the
>> language has it, doesn't mean you have to use it.
>>
>> (2) For a large project, it's essential. And moreover, it needs to be
>> transitive by default.
> 
> But wait... if there wasn't any const in the first place, the guy wouldn't have needed to hack up that workaround... I'm sensing a different moral here... ;-P

First, I'm not convinced that cluebie wouldn't have just casted away 
const to work around D's transitivity.

Second, along the same lines as Robert's reply, if you created a library 
for which in your words "the obvious way" was not the right way to use 
it, and three developers had to ask you how it works, then it sounds 
like you may not have documented your cleverness sufficiently.  Maybe if 
you hadn't been thinking compiler errors from constness would save you, 
then you would have either designed it so that it just worked "the 
obvious way" or at least documented it more thoroughly.

Or was it documented clearly and people just ignored the documentation? 
  That can certainly happen, too.

--bb