On Sun, 30 Aug 2009 18:31:33 -0400, Graham St Jack
<graham.stj...@internode.on.net> wrote:
I have been trying (again) to start using const and immutable objects in
a project, and found I kept getting stuck with the need to change the
value of object references, which isn't allowed. I don't quite follow the
arguments that mean that this has to be the case, but I'm prepared to
accept them.
After some experimenting with Andrei's Rebindable template, I still
couldn't get past the problems. For a start, the get method is private so
I couldn't test for null.
In the end I cooked up the following, which is a very simple workaround
that just lets me assign to a const or immutable object reference. It
works just fine, and can be used in templates like containers without
forcing the container to care about what it is containing.
Comments?
First, a little history lesson. An earlier version of const had this
distinction:
class C {}
const(C) c; // c is rebindable, what it points to is const
const C c2; // c2 is not rebindable.
The const(C) format was modeled after pointers and arrays, i.e. const(C)[]
and const(C)*, but since the "reference" is not explicitly stated, it's
invisible in the const format also :)
So that was thrown out because it was determined that const(...) should
mean that anything inside the parentheses should be const (including a
class reference). What followed was several attempts (including some by
me) to come up with a way to denote a tail-const class reference. Most of
them centered around "pulling out" the reference part, i.e. ref const(C)
or const(*C)*. Others included new keywords. In the end, none of them
looked great, and none of them made Walter change his mind. So via
syntax, there is no way to say "rebindable reference to const class
data." So to answer your first question, there's no objection by Walter
and crew as to being able to rebind a const class reference, there's just
no good syntax to denote it (that has been presented so far anyways).
Then Andrei came along with Rebindable, and the argument died down. I had
a feeling that Rebindable would be somewhat unusable in its current form,
but given that we were about to get opImplicitCast and other niceties, it
seemed Rebindable would be sufficient in the future.
OK, so now we have alias this which is supposed to be the implementation
of opImplicitCast, and you say it's still too difficult. Looking at the
source, it looks like Rebindable needs some attention, as it still doesn't
use alias this. I have no idea if there is a way to implement !is null,
but I assume that it should be forwarded to the alias this member.
So I think a bug report is in order. Rebindable should not use opDot, but
rather alias this. Implicit casting is paramount to make Rebindable look
like a transparent wrapper.
-Steve
