On Thursday, July 15, 2010 17:40:26 Gareth Charnock wrote:
> So having got a collectors' edition TDPL, I though I'd have a try at
> writing some concurrent code. The idea was a worker thread(s) would do
> some work and write the results to some immutable objects. These would
> get passed to an indexer thread that would do neat stuff like indexing
> the references to the objects in things like hash tables and such,
> performing any reduce type operations along the way. These views would
> then be passed back to workers in due course. Unfortunately I hit a
> snag. It appears you can't do this:
>
> class A {
> ...
> }
> immutable A a1 = new immutable(A); //pointer to a real, immutable object
> immutable A a2; //pointer to null
> a2 = a1; //error, guess I doomed a2 to a life of being useless
>
> I thought that as such assignments don't change the underlying objects
> in memory, they would be fine. Compare to:
>
> immutable(char)[] s1 = "hello world"; //fat pointer to a section of
> immutable memory
> immutable(char)[] s2; //fat pointer to null
> s2 = s1; //fine
>
> The only solutions I can think of:
> 1) Use a pointer to a class. Works, but that just seems very unsafe and
> just plain un-D-ish. We also have to dereference two pointers.
> 2) Work entirely with immutable(A)[], which is not quite as crazy as it
> seems as we are copying about arrays of pointers rather than arrays of
> A. It's still quite crazy.
> 3) Write some sort of wrapper struct to hide the pointer.
> 4) Perhaps ref works like C++ int&?
> ref immutable(A) ref_a //error
> Nope.
>
> So is this intended behavior? Am I missing something obvious?
First off, you're using using a reference, not a pointer. They're similar but
quite different. If you were using a pointer, you could do
immutable (A)* a1;
and the object would be immutable while the pointer would be mutable. It's a
mutable pointer to an immutable object of type A. The problem with a reference
is that it has no syntactic way to differentiate between what's doing the
refering and what's being referred. Because immutable is transitive,
immutable A a1;
is an immutable reference to an immutable object of type A. As soon as you try
and make a reference immutable, what it refers to is immutable as well. There
is
no syntactic way to fix the problem. The solution is Rebindable!(T) in
std.typecons.
Rebindable!(T) is a wrapper struct. It allows you to have const and immutable
references and still change what they refer to. Take this example from the docs:
// Rebindable references to const and immutable objects
void bar()
{
const w1 = new Widget, w2 = new Widget;
w1.foo();
// w1 = w2 would not work; can't rebind const object
auto r = Rebindable!(const Widget)(w1);
// invoke method as if r were a Widget object
r.foo();
// rebind r to refer to another object
r = w2;
}
By wrapping the const (or immutable) Widget, you can "rebind" what is "bound"
by
Rebindable!(T) and effectively get a mutable reference to a const or immutable
object. It's not terribly pretty, but apparently no one could come up with a
satistfactory way of doing it in the language itself given the syntax for
references. So, Rebindable!(T) is the solution.
- Jonathan M Davis
