On 29/11/2010 23:04, Walter Bright wrote:
Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:58:10 -0500, Walter Bright
<newshou...@digitalmars.com> wrote:

Steven Schveighoffer wrote:
Having a logical const feature in D would not be a convention, it
would be enforced, as much as const is enforced. I don't understand
why issues with C++ const or C++'s mutable feature makes any
correlations on how a D logical const system would fare. C++ const
is not D const, not even close.


Because people coming from C++ ask "why not do it like C++'s?"

I don't get it. A way to make a field mutable in a transitively-const
system is syntactically similar to C++, but it's not the same. Having
a logical-const feature in D does not devolve D's const into C++'s
const. If anything it's just a political problem.

Having mutable members destroys any guarantees that const provides.
That's not political.


That is not true, trivially. (assuming we are talking about D)

Having mutable members only (slightly) modifies the guarantees of const. For example:

class Foo {
  int x, y, z;
  mutable int blah;
}

void someFunc(const Foo foo) { ... }


here someFunc is still guaranteed to not modify any data transitively reachable through the foo reference, _with the exception of mutable members_. Is this still a useful guarantee? Well yes, for example in Peter's Matrix example, I could pass a const(Matrix) as an argument and still be confident that at most, only the mutable members would be change (the cached determinant), but not the logical state. The compiler would be able to check this, just as much as with D's current const.

Also, it would still guarantee that immutable data passed to that function is not transitively modified (with the exception of mutable members). And that is the main point of const.


A more interesting question is whether mutable members would significantly alter the guarantees of *immutable*. They would not changue the guarantee of immutable with regards to single-threaded optimization. So if a function has an immutable object, it can still assume the non-mutable members don't change, and optimize accordingly.

However, a big thing that could no longer be guaranteed, is that you would be able to safely pass an immutable object to a function running in another thread, without synchronization. This is because said function would be allowed to mutate the mutable members, but these could be being accessed concurrently, so...


--
Bruno Medeiros - Software Engineer

Reply via email to