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