Stepping back and looking at constness from another angle.

Bill Baxter dnewsgroup at billbaxter.com
Mon Jun 4 17:52:49 PDT 2007


Jarrett Billingsley wrote:
> What I'm asking you more seasoned programmers, and those more experienced 
> with const-correctness to do, is to do something similar here.  Step back, 
> and have a look at what constness is for.  What problems does it solve?  Is 
> it necessarily the best way to solve them?  More importantly, what problems 
> does it introduce?  Remember, how the language _looks_ is just as important 
> as the features it has.  After all, what do you want to look at for hours on 
> end each day if you use it at your job?

Great question.  A little brainstorming look-aside never hurt.

The problem in a nutshell is to make it possible to prevent variables 
from changing when you don't want them too.  Knowing they won't change 
makes large systems easier to understand.

Here's a thought I had a while back.  Actually, the #1 practical thing I 
want const for is to make it possible to pass a big struct efficiently 
to a function and know for certain that the caller's value won't be 
modified.

Taking a cue from the removal of 'virtual' from D, one thing D could do 
would be to automatically choose to pass variables by reference based on 
performance criteria.  Have the compiler let me write:
     Vec4f add(Vec4f rbga1, Vec4f rgba2) { }
and not have to worry about whether it would be more efficient to pass a 
const ref there.  People pass const refs all over the place in C++ not 
because they want reference semantics, but because they want reference 
performace.  So let the compiler worry about the optimization, not me. 
I'll specify the semantics, and you, Mr. Compiler, figure out how to 
make it efficient. That's basically what Walter's done with virtual, 
which is great.  One less low-level thing for me to worry about.

The crux there is that I really don't care how it gets passed under the 
hood as long as it's efficient and behaves as if it were passed by value.

Of course that doesn't help object parameters which are references to 
begin with.  There I don't see much way around specifying 'const' in the 
signature.

I'm honestly not too excited by the invariant flavor of const.  I guess 
it's useful for parallel code.  But I don't write a lot of parallel 
code.  Of course we're probably all going to be writing a lot more 
parallel code in the upcoming years, so I'm willing to go along with the 
"eat your peas" message believing it will be good for me in the long 
run.  :-)

In terms of a real, comprehensive answer to your question (as opposed to 
just a trick for struct parameters), I think the two main alternatives 
you see are 1) functional programing languages 2) the ostrich approach.
In pure functional languages, everything is immutable, so problem 
solved.  It's the compiler's job to try to make it efficient.  But 
approach 2), put your head in the sand and ignore it, is also quite 
popular.  Especially for dynamic scripting langauges.  Python for 
instance has no const at all.  I can't remember seeing const in any of 
the scripting languages I've used.  I don't think any of Perl or PHP or 
Ruby or Tcl or Javascript has it.  C obviously got along fine for a long 
time without C++-like const semantics (not sure if that's changed in C99 
though).  I wonder what Pascal/Delphi do?

I guess all I can say is that once you get used to using const like in 
C++, you get an uneasy feeling any time you see a function signature like:
    foo(MyClass a)
You think "whoa -- maybe that's going to modify the object I pass in". 
Whereas with a single 'const' there you can know that it's not 
*supposed* to modify 'a', and if it does (via casts or other 
subversions) then it's probably a bug in the library.  You can do that 
with comments, too, but the compiler won't tell you when your comment is 
out of sync with what the code actually does, so the comment has less 
chance of reflecting reality than a 'const' in the declaration does.

The question is whether the end result is really worth the effort.  I 
don't really know.  I had thought so, but it really has to be weighed 
against the inconveniences introduced by the new design for const, which 
we can't be sure of right now.  But I think it's a very valid question. 
  If the safety line preventing you from falling off the cliff gets you 
all tangled up and in the end ties one of your hands behind your back, 
then clearly things have gone too far.

--bb



More information about the Digitalmars-d mailing list