I just got it! (invariant/const)

Janice Caron caron800 at googlemail.com
Wed Apr 9 11:40:38 PDT 2008


On 09/04/2008, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
>  A function does not necessarily need to take an invariant 'this' pointer to
>  be pure.
>
>  For example:
>
>
>  class C
>  {
>    invariant int x;
>
>    pure int getX() { return x;}
>  }
>
>  void foo()
>  {
>  C c = new C;
>  c.getX(); // ok
>  }

OK, I'm gonna risk it. :-)

Andrei proposes a new feature, *invariant constructors*, which are
constructors with special rules to ensure that pointers to mutable
memory, however, my interpretation of accu-functional.pdf is that
invariant constructors will cause the /entire class/ to be created
invariant. Thus, one would write

    class C
    {
        int x;

        this(int n) invariant
        {
            x = n;
        }

       int getX() invariant pure
       {
           return x;
       }
    }

    invariant c = new C(4);
    int n = c.getX;

My interpretation is that the invariant constructor will construct a
/completely invariant/ object. In that case, there can never be any
such thing as a non-invariant C.

What you're describing is something different - a non-invariant class
with invariant members. Well, the only time you can assign an
invariant member is at compile-time. That means they have to be
assigned with compile-time constants. That, in turn, means they might
as well be static, because they are not going to differ from instance
to instance. And /that/ means you can rewrite your counterexample as

    class C
    {
        static invariant int x = 4;

        static int getX() pure
        {
            return x;
        }
    }

    auto c = new C(4);
    int n = c.getX;

Now getX() is pure because it's static, and therefore /has/ no this pointer.

In conclusion, it may well be that D will insist that all parameters
of pure functions be completely invariant. I don't know that for
/sure/, but that would be my guess.



More information about the Digitalmars-d mailing list