Legal immunity for const
Georg Wrede
georg at nospam.org
Mon Mar 24 19:50:52 PDT 2008
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".
More information about the Digitalmars-d
mailing list