Transitive const sucks

[Christopher Wright]

Alex Burton wrote:
> Basically I think you are trying really hard to kill many birds with one stone: thread safety checkable by compiler, const system for optimisation and lastly const system that is actually usable by programmer.
> This has never been done before and I commend you for working on it.

Right! And the thread safety and optimization stuff is encapsulated in a 
second keyword reserved for functions: pure.

Why is that keyword reserved for functions? Merely tradition?

Though as Janice Caron has demonstrated in another thread, thread safety 
isn't really the sort of thing you want to include incidentally with 
other factors. Pure functions are by definition threadsafe and const; 
logically const functions are not necessarily threadsafe; threadsafe 
functions need not be const.

> I obviously don't know as much about compilers as you but, there seem to be limitations that you dont seem to be able to communicate to us about why you need transitive const.

If you want to ensure thread safety, you either need some sort of mutex 
or you need to be able to say "Nothing will change when I do this, at 
all, so I don't need to worry about thread safety". (Well, regardless of 
whether you can say it, you need it to be true.)

I don't think anyone here disagrees with that assessment. The issue is 
conflating all of const with something that allows such optimizations.

> In the above example what prevents the compiler from changing any calls to multiply to:
> myMathClass.multiply(3,3);
> debug myMathClass.logfile.writeLine("multiply.called");
> 
> So now constness of the actual multiply call are preserved, and we can log the data too.
> 
> Is it because the compiler is unable to see in side other functions unless they are templates - like c++ ?

Right, that's part of the reason.

The rest of the reason is, if myMathClass is const, it's transitive 
const, so logfile is also const and you can't modify its state :)