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