On Wed, 01 Dec 2010 18:34:34 -0500, Walter Bright
<newshou...@digitalmars.com> wrote:
Steven Schveighoffer wrote:
If I see a function like:
void foo(const(C) c);
it doesn't mean that foo cannot modify the object referred to by c, it
just means that foo won't modify data referenced through c. But a C
could store some data in a global variable, possibly even uniquely
associated with each instance (I have shown this in a very old post
proving logical const == const). Then logically, the author of C could
consider that data a part of C. I have no way to stop him from editing
that logical part of C, I'm relying on the author of C not to count
mutable state as part of the state of C.
Adding logical const just provides a location in the object itself for
this data that is not supposed to be part of C's state. It's not
changing the guarantees that const already provides (which is very
little, but helps you follow the correct conventions).
foo() could only modify c if it has, via some other means, acquired a
mutable reference to c. If the user does not provide this other mutable
reference, then foo() cannot modify c. foo() cannot go out and grab or
create such a reference.
You're assuming the domain of c's state stops at its scope. In fact,
except for in pure functions, c's 'state' includes all global variables as
well. There is nothing stopping a programmer from using something outside
the object/struct itself to store some state of c. Those external data
members would essentially be mutable (as I have shown in the past). This
takes most of the teeth out of const's guarantees.
This is quite the opposite from what you're proposing. Currently, the
user has to make it possible for foo() to modify c, whereas your
proposal is that foo() can modify c despite all attempts by the user to
stop it.
Not exactly. My proposal recognizes that we have to trust the programmer
to only use mutable state (or external state in the current const
implementation) to represent 'non-state' variables, that is, variables
that are not considered part of the object itself. This includes
references to unowned data (like an output stream) or cached computations
(which are not part of the state, they are an optimization). My proposal
allows the programmer to store that state inside the object. All const
guarantees on the actual state variables is fully enforced.
The question is, is the user of c concerned about const-ifying data
members that are non-state members? Usually no. They only care about
variables that are part of the state of the object.
Furthermore, if you mark foo() as pure, the compiler can guarantee there
is no such hidden mutable reference.
Pure is an area where logical const would have to follow special rules.
My inclination is that pure functions would have no access to members
marked as 'no-state'. That would at least be consistent with the current
implementation of logical const.
This can have implications as far as copying value-types (what do you do
with the mutable members?), but I think we could work out those rules.
-Steve
