Clarifying 'const' terminology

[Derek Parnell]

I'm not from a C++/C#/Java background, so please excuse my lack of  
understanding about the meaning that is being applied to the term 'const'  
in these recent discussions.

To me, there seems to be two things being talked about.

(a) Data, which once initialized, is not to be modified for the run-time  
life of the application.

(b) Data, which once passed to some function, is not to be modified for  
the run-time life of that function.

Walter's proposed refinement of the 'in' keyword does nothing for type  
(a), and only limited support for type (b), in that it protects data from  
the called function but not from functions that that subsequently calls.  
It is only protection for one level deep. And the only data protected is  
class objects and not other reference types.

Is there any other types (or subtypes) of 'const' meanings being discussed  
or considered?

For example, are we distinguishing between compile-time protection and  
run-time protection?

My requirements for 'const' are almost covered by Walter's new proposal.  
I'm a quite concerned that if I tell Foo() that it can't change something,  
that Foo() can still tell Bar() to disregard my request and tell Bar()  
that it's okay to change it anyway.

I think that apart from array references, type (a) const can be acheived  
through using private members and public properties. I'm not sure how we  
can fully implement (a) with current D semantics.

-- 
Derek Parnell
Melbourne, Australia