What purpose to const besides functional programming?

[Walter Bright]

Jason House wrote:
> Walter Bright Wrote:
> 
>> Jason House wrote:
>>> What *other* purposes does the const system serve besides opening
>>> the door to functional programming?  I understand that the const
>>> system must remain simple to be usable.
>> 1. It makes function APIs self-documenting. 2. Invariance allows
>> one to pass large data structures around by reference yet treat
>> them as if one passed them by value. Strings are the canonical
>> example of that. 3. Const allows one function to service both
>> mutable and invariant arguments. 4. Invariant data can be placed in
>> hardware protected readonly memory, such as ROM. 5. Invariant data
>> does not have to be synchronized to be multithread accessible. 6.
>> Invariant data improves the ability of automated tools to make 
>> inferences about what is happening. Optimization is an example of
>> such.
> 
> #5 is not true.  Invariant functions require synchronization because
> they can manipulate global state.

Not so. The only invariant functions in D are member functions which 
cannot change the state referenced by 'this'. They can certainly change 
other state. Pure functions, on the other hand, may not manipulate 
global state.

> If #5 is restricted to direct data
> access without using properties or member functions, then I'd agree
> with it.  Of course, that qualification eliminates most of the
> benefit from #5.

I think you are confusing invariance with purity. They are distinct 
concepts with distinct rules and uses.


> #2 makes me think a bit...  When would const objects be used to
> manipulate non-const data that isn't effected by transitive const?

I don't understand your question. #2 is about invariance, not const.

> It seems to me that simple cases could work, but it quickly breaks
> down when trying to generalize. For example, I could write a log
> utility that writes messages to standard out.  To write to any
> output, I'd need to store where to write log output to.  Maybe I
> could circumvent the const system and create a global object that
> looks up where to write stuff.  That'd let me pass around my logger
> as an invariant object but then it'd be making an extra function call
> every time something gets logged.  That's a horrible design.
> Advanced compiler tricks may eliminate the overhead, but it doesn't
> mean it'd save headache for the programmer.

It still sounds like you're mixing up purity with invariance.


>>> Pure functions requires that any shared data is invariant.
>> Yes, but invariant data does not require purity.
> I translate that as "I didn't implement it that way".

It shouldn't be translated that way, because invariance and purity are 
fairly common comp sci constructs, and I believe that D uses them in 
conformance with that (although the term 'invariance' isn't used).


> Also, we need
> to distinguish between raw access to invariant data and use of
> (invariant) methods.  See my discussion of your #5 above

No, once again, I think you are confusing invariance with purity. An 
invariant function means that it cannot modify anything through its 
'this'. It can modify anything else.

>> I hope this post will convince you otherwise. If not, I can try
>> again <g>.
> And I can try again too :)

First we need to agree on what purity and invariance are.