unpaintable (the solution to logical const)

[Steven Schveighoffer]

"Simen Kjaeraas" wrote
> On Fri, 04 Apr 2008 14:11:53 +0200, Janice Caron
> 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).

I agree that there seems no reason to have an unpaintable invariant type. 
However, currently the compiler outputs this:

class C
{
    invariant(int)* i;
}

void f(const(C) c)
{
    pragma(msg, typeof(c.i).stringof);
}

outputs:
const(int)*

Which seems to me like a mistake, but there is no harm done because you 
can't change i through a const reference.  Having logical const would 
prevent the painting of i, and then it would remain as invariant(int)*.

Having it be invariant always could potentially have some benefits, such as 
being able to call invariant versions of functions.

-Steve