• Georg Wrede (28/28) Mar 24 2008 If I see the following in a library document or source code

Georg Wrede <georg nospam.org> writes:

If I see the following in a library document or source code

     same_constness_as_arg type func(i_wont_modify type arg)
     {//...
     }

I immediately understand that this function doesn't change its 
argument's contents (or make it point to something else), and that if I 
give it something that I've elsewhere defined as const, it'll return its 
output as const.

Upon seeing this I also immediately grant legal immunity to the function 
and its author, as far as const issues are concerned.

The function's responsibilities start when it is called, and end when it 
returns its return value. There is no way I could even dream of suing 
him for things that I do to the return value after the function returns.

It is clearly obvious that the contents of arg are safe during the 
execution of function, and that this function cannot, and _should_not_ 
need to protect arg thereafter.

The fact that there's "a debacle" going on about this reminds me of the 
const thoughts that led to the recently aborted const foray in D. The 
issues are non-trivial, to say the least.

Wanting to protect arg after the function, really amounts to trying to 
reimplement transitive constness, which we've all seen is virtually 
impossible.


To recap, if I want to forbid anyone from changing my data even "via" 
this function, then I declare (or even cast) arg as const. And if I 
don't care, then I give it a non-const arg. -- However, in both cases I 
know that this function /itself/ won't change anything about arg.

Such a feature in D (as defined here) looks tempting, clear, and very 
usable. See however my previous post "Const unbackled".