unpaintable (the solution to logical const)
Simen Kjaeraas
simen.kjaras at gmail.com
Fri Apr 4 10:56:14 PDT 2008
On Fri, 04 Apr 2008 14:11:53 +0200, Janice Caron <caron800 at googlemail.com>
wrote:
> class C
> {
> T a;
> unpaintable T b;
> invariant(T) c;
> unpaintable invariant(T) d;
> }
>
> If we paint this class const, with the const(...) type constructor, we
> get a const(C) - the fields of which will look like this:
>
> // pseudocode
> class const(C)
> {
> const(T) a;
> unpaintable T b;
> const(T) c;
> unpaintable invariant(T) d;
> }
What reason would exist for having an unpaintable invariant field? As far
as I've understood, invariant is implicitly castable to const, and casting
away const/invariant is a Bad Thing, so whether it is const or invariant
does little difference, except for functions that demand invariant
arguments. In the latter case, the field is in a way 'less constant' when
cast to const than for a normal instance, if I have understood things
correctly (invariant values will not change, const values might change
underneath you).
More information about the Digitalmars-d
mailing list