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".