Clarifying 'const' terminology

[Derek Parnell]

On Sun, 09 Jul 2006 05:45:50 +1000, Bruno Medeiros  
<brunodomedeirosATgmail at SPAM.com> wrote:

> Derek Parnell wrote:


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

>> I'm not sure how we can fully implement (a) with current D semantics.

> I'm assuming that in that that last "(a)" you meant "(b)".

No actually. I really did mean (a). So far as I understand it, all the  
discussions of 'const' still fall into either of these two categories. I  
know that compile-time constants are in category (a). Both styles of  
constants, as implemented in D, are of type (a) because once inititialized  
their value is not allowed to be changed ever by anything. Another type of  
'const' that falls into (a) is the 'const' returned value. I see that as  
being that some function creates data and asks that no one change it while  
the data exists. This type of (a) is the one that I can't see how to  
implement in current D.

The (b) category is easy to implement in D currently. Just pass a copy of  
the data to a function, then the function, and other functions that it may  
call, can play with the copy until it's heart's content with no harm done  
(apart from side effects <g>). But this method is can obviously be a  
performance hit, plus it doesn't help track down mistakes in the called  
functions - that is when the called functions accidently attempt to change  
data it knows it shouldn't.

So in summary, I believe that D does not completely implement either of  
the two 'const' categories at all. And everyone, including Walter, seems  
to agree on that point. What there seems to be some disagreement on is  
whether or not D is obliged to implement 'const'.

-- 
Derek Parnell
Melbourne, Australia