const and immutable objects

[Steven Schveighoffer]

On Sun, 30 Aug 2009 18:31:33 -0400, Graham St Jack  
<graham.stjack at 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