On Friday, 17 August 2012 at 02:33:46 UTC, Chris Cain wrote:
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)
Thanks... I promise I'm not >__< I'm just having trouble seeing
what guarantees anyone is getting.
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:
Ok thanks for trying again. :)
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.
Yup, just like in C++.
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.
Yup, so far so good.
y is your const view of your data. No matter how hard you try
(without casts), you can't mutate y.
Yup.
You _can_ mutate x, which y is viewing. The y view updates
accordingly, but you didn't mutate y.
Yup.
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
Nope, not what I said. :)
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.
Yes, I already understood this, and I'm pretty sure I still do.
What you're saying, I understand.
What is seems to be missing is the answer to my question:
What _guarantees_ can the compiler make about your code, /based/
on the fact that y is a const view, or that the entire struct is
const?
You keep on telling me that y is a const view, which, obviously,
it is.
But the question is: why is that useful, compared to C++?
e.g. What kind of a guarantee can a D compiler make about code
that calls a const method, which a C++ compiler probably wouldn't
be able to?
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.
"Hacking around", I guess you could put it. :-D
As well as trying to clarify things for other people who might
have the same questions as well (which I'm sure they would).
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.
It's not a question about misuse, it's a question about
guarantees. The compiler simply _isn't_ allowed to do something
that works for 99% of code, while breaking that 1% that misuses
it (but is legal).
i.e. It's a code generation issue, not a misuse issue.
(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.)
Well ok, nice speaking with you then. :)
