unpaintable (the solution to logical const)

[guslay]

Simen Kjaeraas Wrote:
> 
> 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).


Wow. I should have read this thread earlier today.

I too don't see a reason for "unpaintable invariant". If you wrap a class in a const() or invariant(), the constness of its field should only be allowed to increase. c would have to remain invariant.

We could define unpaintable/mutable as fields that escape constness promotion. In this scheme, "unpaintable const" would be possible (not sure if it would be meaningful). Such field would remain const in invariant(C).

I feel that it would be a little bit complicated. I would stick to field being labeled:

unlabeled - follow constness promotion
const - at least const, might be promoted to invariant.
invariant - never less than invariant
unpaintable (mutable) - don't follow constness promotion


For my part i like mutable. I think it would have in D the exact same meaning it has in C++. But that's a war that would never end.