Logical const

[Jonathan M Davis]

On Sunday 28 November 2010 03:13:03 Peter Alexander wrote:
> I'm a little worried by the lack of replies. I'm beginning to get the
> feeling that the D way of doing this is to rewrite the const-ness of
> your program :-(
> 
> I guess I'll just stick to not using const for now until this is resolved.

Walter is certainly against logical constness, so it's not like the situation is 
likely to be set up to do it cleanly. IIRC, Andrei said something at one point 
about it being possible to do it with a library solution, but I have no clue 
how. Certainly, looking at the situation, it looks like you either make it truly 
const or you don't make it const at all.

I believe that in theory if you are _certain_ that a const variable is in 
mutable memory and is really const and not immutable, then you can safely cast 
away the constness and do whatever it is that you need to do. But you don't 
usually have such guarantees.

If you play games with global or class variables where the variable that you 
want to be mutable in spite of the object's constness is not actually in the 
object, then you should be able to get around the problem that way, but then the 
variable isn't really part of the object anymore, and it throws purity out the 
window.

So, _I_ am certainly not aware of a good solution, but if you play games, you 
should be able to get _something_ working. Overall though, I think that the 
lesson is that you should really be making const functions truly const and not 
try and deal with logical const at all.

But honestly, given some of the issues with const - particularly the lack of 
const-correctness for Object and the fact that inout is completely broken - I 
think that most people are currently avoiding const, so you're not going to have 
very many people who have messed with the problem and found an appropriate 
solution. Personally, I've just settled for either making functions truly const 
or giving up on their constness (much as I _hate_ to do that).

- Jonathan M Davis