Callee vs caller const (Was: D - more or less power than C++?)

[Kevin Bealer]

In article <440E2E4C.6090902 at nospam.org>, Georg Wrede says...
>
>Johan Granberg wrote:
>
>>> 3. read only sematics that work as a strong reminder that one is
>>> not suposed to modify somthing (but can be subverted by a cast) 
>
>(Just a thought:)
>
>I wonder if everybody here is thinking like this:
>
>void foo(const int arg)
>{
>     // whatever
>}
>
>void main()
>{
>     int bar = 3;
>     foo(bar);
>}
>
>Now, suppose we change the whole thing into:
>
>void foo(int arg)
>{
>     // whatever
>}
>
>void main()
>{
>     int bar = 3;
>     foo(const bar);
>}
>
>---
>
>Comments? Ideas?
>
>In non-release code the calling code could inclucde implicit tests for 
>variable "sameness", i.e. check that the value is unchanged over the 
>function call. That way the callee could simply be unaffected by this 
>new twist. Right?
>
>After all, it's the calling code that's interested in "constness", not 
>the callee. Or have I missed something?

Other people have proposed this... its probably possible but would be costly.

You could do this and get nearly the same effect:

foo(bar.dup);

Of course, it would not work for int, but you don't need it for those.  It would
also not be "deep" constness, which would be hard to do in your method also.

I think the "deep" equality and "deep" const, and recursiveness of const (i.e.
const to sub-functions and sub-objects) is most of what makes it hard to
implement.

I've often found that const "catches" me in C++, but what it saves me from is
usually just "lack of const correctness".  I'm not sure how often it has
actually saved me from writing bad code.  In any case, Walter doesn't see a big
enough benefit from it.

I have an idea on const that I'll sketch up and post in a sec.

Kevin