unpaintable (the solution to logical const)

[Steven Schveighoffer]

"Janice Caron" wrote
>I was wrong. Stephen was right. (This is great, actually. I love being
> wrong because every time I'm wrong, I learn something new. Plus, I
> love the debate). Still, I must bow my head to the superior argument.
>
> I'm pretty good at explaining stuff, once I understand it, so I'm
> going to try to do that, right now.

I'm not very good at it apparently :)  Glad to see I finally did though...

> What we do is this: we classify every field of a class/struct/union as
> being either "paintable" or "unpaintable". (Fields which would be
> called "mutable" in C++ are called "unpaintable" here).
>
> When the type-constructor const(...) is applied to a type, all
> paintable fields are recursively painted const. (Unpaintable fields
> are left alone). That's it!

I like the idea, but not the keyword.  It is exactly what I was thinking.  I 
don't like the keyword because it looks to me like pain-table and 
un-pain-table :)

> One thing Steven /didn't/ think of (or at least, didn't tell us about)
> is that it is perfectly possible for a field to be simultaneously both
> paintable and invariant.

>From my original post:

"mutable is used as the keyword in C++ to describe this type.  However, I do
not like this word..."

"...We need a word that says "this isn't affected by
const or invariant, but it could already be const or invariant".  Something
that is short and not heavily used in code.  Mabye even some form of
punctuation."

So you  must have missed it.  It was at the bottom, I guess that should have 
been more prominent.

-Steve