Stepping back and looking at constness from another angle.

[Charlie]

As far as I can tell 'const' is just a guarantee by the person that 
wrote the function that said function won't modify your variable , and 
if it tries the compiler won't let it and tell you so.

In C++ I think most people always pass by const reference, and like Bill 
said once you see a function signature that doesn't include const you 
get a little panicked, maybe because not having const for parameters 
doesn't tell you wether or not it _will_ modify you're variable, it only 
says it _might_.

So maybe we need something that guarantees that it will be modified 
instead, and have const the default ( has this already been discussed ? 
).  That way there wont be 'will it or wont it' , it will be clear that 
this function intends to modify the variable .  I think its more often 
the case that a function doesn't intend to modify your variable.

Or maybe , instead of having the function guarantee the const'ness, have 
a keyword for parameters when calling a function, that tells the 
compiler , 'if this function tries to modify this variable, then error 
out and tell me about it' , something like:

foo( const myInstance );

Or the opposite is probably better, make it always error out when the 
function tries to modify it, and only when you expect it to do the 
modifying you pass it : foo( mod myInstance );  ( Ignore the syntax, 
just the idea ).

Just brainstorming,
Charlie



Bill Baxter wrote:
> 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