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