What guarantees does D 'const' provide, compared to C++?

[Chris Cain]

On Friday, 17 August 2012 at 02:01:11 UTC, Mehrdad wrote:
>...snip...
>
> Are you sure?

I've already responded to something that is equivalent to what 
you just posted. I'm not sure if you're intentionally being 
obtuse (I'll give you the benefit of the doubt) or if your eyes 
are glossing over when you get to the important parts of my 
posts, but in either case I don't feel like repeating myself 
again. For your benefit, I'm repeating myself as clearly as I can:

Const is basically a view of your data. If you have something 
that's const, it's like looking through a filter that only allows 
you to do certain things. It is _not_ a guarantee that it's the 
only view of your data that exists in the universe. Your code, 
again, shows that you have two views of your memory. x is a 
mutable view of your data, and you're mutating it. y is your 
const view of your data. No matter how hard you try (without 
casts), you can't mutate y. You _can_ mutate x, which y is 
viewing. The y view updates accordingly, but you didn't mutate y.

Maybe in a second you'll say "oh, but that's mutating y" and I'll 
promptly ignore you completely this time because you've yet again 
missed the point:2

You mutated x, not y, y is a view on the same data that x is so 
mutating x would logically have y's view updated since const 
isn't a guarantee that you only have one view of the data and 
thus blah blah blah ... would be my ad infinitum response.



Let me point this out: It's there to give you guarantees and ways 
to think about your code and to allow you to use the same code 
for mutable and immutable data. That's it. There's no magic 
behind it that you're not getting. The idea is that if you want 
those particular features in your code and you know you can use 
them effectively, then you use const. Generally, if you want the 
same code to work on mutable data and immutable data, then you 
have to use const. It's a bridge that allows the same code to 
work with either type. You can use this so that you reduce code 
duplication (and work for you) or/and reduce the amount of 
instructions loaded in your CPU (potentially reducing the times 
when your cache is reloaded) or I'm sure there's other good 
reasons as well, but that's for you to figure out. It isn't a 
catch all feature. Not everything needs to be bashed with the 
const golden hammer of doom without any thought behind why you 
might want it to be const. There's plenty of times where you 
don't want to use const because it simply doesn't make sense and 
it doesn't give any additional meaning to your code. But that's 
okay, you just don't need to use const when it doesn't do 
anything for you.


Your main problem seems to be that you're intentionally trying to 
break const as hard as you can. Obviously, there's nonsensical 
ways to use const, and I don't think anyone would argue that 
_any_ feature is completely bulletproof to incompetence. Take 
classes for instance. Do I really need to give you an example 
that grossly misuses classes? Does that mean that classes have no 
purpose? Should I always use structs or parallel arrays because 
classes can be misused?

Instead of trying to misuse the feature, you ought to be spending 
your energy trying to use the feature for your benefit.


(I'm going to make this the last post on the matter ... I'll 
respond to Mr. Davis' concern on the bug in just a minute, but 
I've made my full effort to explain const to you and I don't see 
where additional conversation on my part can clarify this any 
further.)