• Alex Burton <alexibu mac.com> Sep 12 2007
• Christopher Wright <dhasenan gmail.com> Sep 13 2007
• Sean Kelly <sean f4.ca> Sep 13 2007

Alex Burton <alexibu mac.com> writes:

Walter Bright Wrote:

 Janice Caron wrote:
 Even something as simple as this needs logical const
 
 class MyMathClass
 {
     invariant int multiply(int x, int y) /* logically const */
     {
         debug logfile.writeLine("multiply.called");
         return x * y;
     }
 
     debug private Stream logfile;
 }
 
 You can't tell me that's not a real world need.


 You can:
 
 1. make logfile a static member.



 2. not use invariant on the multiply. After all, if it isn't actually 
 invariant, the invariant declaration wouldn't have any more meaning than 
 the comment you put on it.


It is far more than a comment. This class may be passed all through an
application and as long as only const references to MyMathClass are we can be
sure that all this code is not calling any other non const methods, only the
ones marked as invariant which don't change the state of MyMathClass.
Without transitive const, the logfile might be changed, but who cares, it's not
part of the MyMathClass and no contract was made about modfying objects other
than the current instance of MyMathClass.

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.

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.

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++ ?

Christopher Wright <dhasenan gmail.com> writes:

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 :)

Sean Kelly <sean f4.ca> writes:

Christopher Wright wrote:
 Alex Burton wrote:
 
 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.)


A third option for thread safety would be if the function mutated only 
atomic non-local data.  The function wouldn't be 'pure' however.


Sean