On Tuesday, 10 July 2012 at 02:43:05 UTC, Era Scarecrow wrote:
On Tuesday, 10 July 2012 at 01:41:29 UTC, bearophile wrote:
David Piepgrass:
This use case is pretty complex, so if I port this to D, I'd
probably just cast away const/immutable where necessary.
You are not the first person that says similar things. So D
docs need to stress more than casting away const/immutable in
D is rather more dangerous than doing the same thing in C++.
...
Let's say a class/struct is a book with Page protectors
signifying 'const(ant)'. You promise to return the book to the
library without making any changes; Although you promised you
wouldn't make changes, you still take the Page protectors off
and make make notes on the outer edges or make adjustments in
the text, then return the book.
Is this wise? This isn't C++. If something shouldn't change,
then don't change it god damn it. If it needs to change it
isn't const(ant) and shouldn't suggest it is.
The difficulty, in case you missed it, is that somebody else (the
Object class) says that certain functions are const, but in
certain cases we really, really want to mutate something, either
for efficiency or because "that's just how the data structure
works". If a data structure needs to mutate itself when read,
yeah, maybe its functions should not be marked const, but quite
often the "const" is inherited from Object or some interface that
(quite reasonably, it would seem) expects functions that /read
stuff/ to be const.
And yet we can't drop const from Object or such interfaces,
because there is other code elsewhere that /needs/ const to be
there.
So far I have no solution to the dilemma in mind, btw. But the
idea someone had of providing two (otherwise identical)
functions, one const and one non-const, feels like a kludge to
me, and note that anybody with an object would expect to be able
to call the const version on any Object.
Seriously, it's not that hard a concept. I guess if something
doesn't port well from C++ then redesign it. Some things done
in C++ are hacks due to the language's limitations and faults.
I was referring to a potential port from C#, which has no const.
My particular data structure (a complex beast) contains a mutable
tree of arbitrary size, which the user can convert to a
conceptually immutable tree in O(1) time by calling Clone(). This
marks a flag in the root node that says "read-only! do not
change" and shares the root between the clones. At this point it
should be safe to cast the clone to immutable. However, the
original, mutable-typed version still exists. As the user
requests changes to the mutable copy in the future, parts of the
tree are duplicated to avoid changing the immutable nodes, with
one exception: the read-only flag in various parts of the
original, immutable tree will gradually be set to true.
In this case, I don't think the D type system could do anything
to help ensure that I don't modify the original tree that is
supposed to be immutable. Since the static type of internal
references must either be all mutable or all immutable, they will
be typed mutable in the mutable copy, and immutable in the
immutable copy, even though the two copies are sharing the same
memory.
And one flag, the read-only flag, must be mutable in this data
structure, at least the transition from false->true must happen
*after* the immutable copy is created; otherwise, Clone() would
have to run in O(N) time, to mark every node read-only. This
fact, however, does not affect the immutable copy in any way.
