What purpose to const besides functional programming?

[Jason House]

Walter Bright Wrote:

> Jason House wrote:
> > Simen Kjaeraas Wrote:
> >> You are expecting invariant member functions to not do things they
> >> can and should do.
> > 
> > My example was in response to Walter's statement (#5) that invariant
> > objects can be accessed without synchronization.  I was providing a
> > simple counter example.
> 
> The counter example was changing global state, not the invariant object. 
> The statement #5 is correct - the counter example did not change the 
> invariant object's state.


Let’s dissect the original statement #5 and all of it’s possible meanings:
5. Invariant data does not have to be synchronized to be multithread accessible.

Invariant data:
  This would be various forms of invariant(T) with different T’s.  It’s possible that T is just fundamental types such as int and float, but I think that’s unlikely.  Given other goals such as using reference types as value types, this has to include classes and structs.  I’d also assume from this that common uses of the various types would have to be included.  This would mean classic OOP styles such as data encapsulation.

Does not have to be synchronized:
  I interpret this as “never requires synchronization” while others have interpreted it as “might not need synchronization”.  I can’t believe the latter because of how much Walter has said in the past about the inherent dangers of multi-threading and an inability to trust programmers to conform to best practices.

Multithread accessible:
  If this doesn't mean "safely accessible by multiple simultaneous threads without incorrect or undesired outcomes", then there's no point is claiming anything about multi-threading.
  What is meant by "accessible"?  For strings, this clearly means reading the characters within the string, but when expanded to all types of invariant data, the meaning is less clear to me.  As discussed above, invariant data needs to cover the case of data encapsulation.  Proper encapsulation means that _no_ data members are exposed for direct access and that all access must be through member functions.  If object are to be multithread accessible, then the access functions must be included.

All of the above drives me to believe that the original statement #5 implicitly includes the statement that “All compilable calls to member functions of invariant objects can be done without synchronization”.  It’s become pretty clear that most people disagree with that conclusion.  

In my original reply to Walter, I said “If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it.”  I didn’t think that was such an outlandish statement or possible requirement that Walter left out.  I said it before, and I’ll say it again: “Of course, that qualification eliminates most of the benefit from #5.”

It’s amazing how such basic stuff can completely spiral out of control with people claiming that I don’t know what I’m talking about and assuming all kinds of inaccurate stuff.  It’s not like I wasn’t aware that extending Walter’s statement to include “invariant (member) functions” was possibly contentious.  Simply agreeing that statement #5 should be qualified as direct member access would be sufficient to end the problems with this bit of the conversation and move on to more productive conversation.

I don’t have the time to write long and verbose posts like this one to explain the tiniest bits of stuff that I’m talking about.  Beyond being annoying, huge posts about the littlest details will prevent anyone from reading the post or simply losing sight of the forest through the trees.  I’m done talking about this topic!