Another Transitive const solution

Alex Burton alexibu at mac.com
Wed Apr 9 15:18:34 PDT 2008


Steven Schveighoffer Wrote:

> "Alex Burton" wrote

> 
> If D's invariant system isn't transitive, it means that just because I 
> declare a C as invariant doesn't make what the members reference invariant. 
> Then the pure function isn't allowed to dereference member, because it's not 
> sure if member is invariant or not.  We can add keywords to declare that a 
> member should be invariant if the class is invariant, but then the author of 
> the class has to know that his class will be used in pure functions.  If the 
> author doesn't care, then another author writing a pure function cannot use 
> C's members, even if C is invariant, and what we are left with is a bunch of 
> code that doesn't work with pure functions.  The goal is to make FP 
> possible, not hinder it.
> 
> What we want is to have what is most common be the default, that any 
> variable declared inside a class is part of the class by default, and 
> therefore, affected by transitive const/invariant.
> 
> We already have exceptions that say 'this isn't part of the class', such as 
> static.  What we don't have yet is a way to declare that a variable is not 
> part of the class but is stored with the class instance.
> 
> >
> > Transitive const could still be useful for goal 2 like this :
> >
> > class A
> > {
> > int value;
> > void set(int x)
> > {
> > value = x;
> > }
> > const int get()
> > {
> > return value;
> > }
> > };
> >
> > class B
> > {
> > part A a1;
> > A a2;
> > const int get()
> > {
> > a1.set(7); //compilation error - can't modify a1 in const member function 
> > because it is part of B
> > a2.set(5); //ok a2 can be modified as it is not part of B it is just an 
> > object that we are looking at.
> > return a1.get()*a2.get();
> > }
> > };
> >
> > So introduce a new keyword : "part" or similar and then we have a powerful 
> > const system for goal 2.
> > And leave goal 1 for the pure specifier and future developments.
> 
> You are saying, let's have variables declared inside a class NOT be 
> considered part of the class unless you use the 'part' keyword?  While this 
> is a way to solve the problem, I think this would be very error prone.  What 
> most people are used to is that when they declare a variable inside a class 
> scope, by default it's a member of the class instance.  With your scheme, 
> what you will end up with is people will seldom use the 'part' keyword, and 
> when pure functions come around, they cannot use any of the non-'part' 
> members.  As a result, nobody will use pure functions except for simple math 
> functions.  This is not what Walter wants, and if we are going to have pure 
> functions, it's not what I want either.  I like how D const is transitive by 
> default, although I think there should be a way to make exceptions to that 
> rule.

I agree, the most common case should be the default. The concept would stay the same though.
Whether the keyword is part or notpart or something else I don't know.
The basic concept is that reality tells us that not every part of a piece of software is part of every class.
Transitive const is at odds with reality, because it assumes that all objects that are members of a class are necessarily part of that class.

Alex



More information about the Digitalmars-d mailing list