www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const and immutable objects

reply Graham St Jack <graham.stjack internode.on.net> writes:
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?

//
// Assign dest to src, using brute-force methods as necessary if T
// is an immutable or const object.
//
// The intent is to avoid needing routine nasty tricks in
// application code, especially in template code which should be
// spared the complication of handling this very annoying
// restriction on objects. Use of this template function doesn't
// let you change the object itself, just the reference to it - so
// all should be well.
//
void forcefulAssign(T)(ref T dest, T src) {
    static if (!is(T X == const(U), U) &&  !is(T X == invariant(U), U)) {
        // T is not const or immutable - just assign normally
        dest = src;
    }
    else static if (is(T : Object)) {
        // T is a const or immutable object - use brute force
        U * ptr = cast(U *) &dest;
        *ptr = cast(U) src;
    }
    else {
        // T is some other const or immutable type - not assignable
        static assert(false, "cannot assign to " ~ T.stringof);
    }
}

// assign the default initializer to something
void forcefulInitialize(T)(ref T dest) {
    static if (!is(T X == const(U), U) &&  !is(T X == invariant(U), U)) {
        // T is not const or immutable - just initialise normally
        dest = T.init;
    }
    else static if (is(T : Object)) {
        // T is a const or immutable object - use brute force
        U * ptr = cast(U *) &dest;
        *ptr = U.init;
    }
    else {
        // T is some other const or immutable type - not assignable
        static assert(false, "cannot assign to " ~ T.stringof);
    }
}
Aug 30 2009
next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Graham St Jack 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?
 
 //
 // Assign dest to src, using brute-force methods as necessary if T
 // is an immutable or const object.
 //
 // The intent is to avoid needing routine nasty tricks in
 // application code, especially in template code which should be
 // spared the complication of handling this very annoying
 // restriction on objects. Use of this template function doesn't
 // let you change the object itself, just the reference to it - so
 // all should be well.
 //
 void forcefulAssign(T)(ref T dest, T src) {
     static if (!is(T X == const(U), U) &&  !is(T X == invariant(U), U)) {
         // T is not const or immutable - just assign normally
         dest = src;
     }
     else static if (is(T : Object)) {
         // T is a const or immutable object - use brute force
         U * ptr = cast(U *) &dest;
         *ptr = cast(U) src;
     }
     else {
         // T is some other const or immutable type - not assignable
         static assert(false, "cannot assign to " ~ T.stringof);
     }
 }
 
 // assign the default initializer to something
 void forcefulInitialize(T)(ref T dest) {
     static if (!is(T X == const(U), U) &&  !is(T X == invariant(U), U)) {
         // T is not const or immutable - just initialise normally
         dest = T.init;
     }
     else static if (is(T : Object)) {
         // T is a const or immutable object - use brute force
         U * ptr = cast(U *) &dest;
         *ptr = U.init;
     }
     else {
         // T is some other const or immutable type - not assignable
         static assert(false, "cannot assign to " ~ T.stringof);
     }
 }
 

I agree that D lacks a mechanism to separate the object from it's reference. Maybe syntax like the following could be used to apply the storage class to the object value, and not the reference value: class Foo; void bar(in Foo& foo) {} It's quite ugly and C-like, but that's the first thing that came to mind. The reference value is unique to the current method and shouldn't share the same storage qualifiers as it's referenced memory.
Aug 30 2009
parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:


 I agree that D lacks a mechanism to separate the object from it's
 reference. Maybe syntax like the following could be used to apply the
 storage class to the object value, and not the reference value:
 
 class Foo;
 void bar(in Foo& foo) {}
 
 It's quite ugly and C-like, but that's the first thing that came to
 mind. The reference value is unique to the current method and shouldn't
 share the same storage qualifiers as it's referenced memory.

I think the time for pining over this particular syntax feature of D is over - as nice as it would be to be able to fix the problem in the language, it would be too disruptive right now. What we need is something in phobos that works around the problem, and Rebindable isn't suitable as it stands because: * It presents different interfaces for different kinds of wrapped types. * It doesn't let you access the wrapped object except via opDot. My suggested workaround is perhaps a bit rough, but it does work. I would like to hear from anyone who is using const and immutable objects in D2 who has something better, or has suggestions to improve my code.
Aug 30 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Graham St Jack Wrote:

 On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:
 
 
 I agree that D lacks a mechanism to separate the object from it's
 reference. Maybe syntax like the following could be used to apply the
 storage class to the object value, and not the reference value:
 
 class Foo;
 void bar(in Foo& foo) {}
 
 It's quite ugly and C-like, but that's the first thing that came to
 mind. The reference value is unique to the current method and shouldn't
 share the same storage qualifiers as it's referenced memory.

I think the time for pining over this particular syntax feature of D is over - as nice as it would be to be able to fix the problem in the language, it would be too disruptive right now.

I think it would be better to fix it in D2 instead of patching a language design flaw with a template. It wouldn't be the first time D2 has changes that breaks existing code anyways (and the upcoming T[new] will definitely break a lot of code, so does shared when it works, etc), so it would be less disruptive to do it now than never do it.
Aug 31 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jeremie Pelletier wrote:
 Graham St Jack Wrote:
 
 On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:
 
 
 I agree that D lacks a mechanism to separate the object from it's
  reference. Maybe syntax like the following could be used to
 apply the storage class to the object value, and not the
 reference value:
 
 class Foo; void bar(in Foo& foo) {}
 
 It's quite ugly and C-like, but that's the first thing that came
 to mind. The reference value is unique to the current method and
 shouldn't share the same storage qualifiers as it's referenced
 memory.

D is over - as nice as it would be to be able to fix the problem in the language, it would be too disruptive right now.

I think it would be better to fix it in D2 instead of patching a language design flaw with a template. It wouldn't be the first time D2 has changes that breaks existing code anyways (and the upcoming T[new] will definitely break a lot of code, so does shared when it works, etc), so it would be less disruptive to do it now than never do it.

I agree with the sentiment. The issue is, however, that the change adds a fair amount of complexity to the const system for an arguably not-often-used need. Andrei
Aug 31 2009
next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu Wrote:

 Jeremie Pelletier wrote:
 Graham St Jack Wrote:
 
 On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:
 
 
 I agree that D lacks a mechanism to separate the object from it's
  reference. Maybe syntax like the following could be used to
 apply the storage class to the object value, and not the
 reference value:
 
 class Foo; void bar(in Foo& foo) {}
 
 It's quite ugly and C-like, but that's the first thing that came
 to mind. The reference value is unique to the current method and
 shouldn't share the same storage qualifiers as it's referenced
 memory.

D is over - as nice as it would be to be able to fix the problem in the language, it would be too disruptive right now.

I think it would be better to fix it in D2 instead of patching a language design flaw with a template. It wouldn't be the first time D2 has changes that breaks existing code anyways (and the upcoming T[new] will definitely break a lot of code, so does shared when it works, etc), so it would be less disruptive to do it now than never do it.

I agree with the sentiment. The issue is, however, that the change adds a fair amount of complexity to the const system for an arguably not-often-used need. Andrei

Correct me if I'm wrong, but I don't see how complex that could be, since the compiler already needs to make the difference between the reference value and the object being referenced. The only thing that would need change is how that view is reflected in the syntax. How about a .ref property? class A {} void foo(in A a) { }
Aug 31 2009
prev sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Andrei Alexandrescu Wrote:

 Jeremie Pelletier wrote:
 Graham St Jack Wrote:
 
 On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:
 
 
 I agree that D lacks a mechanism to separate the object from it's
  reference. Maybe syntax like the following could be used to
 apply the storage class to the object value, and not the
 reference value:
 
 class Foo; void bar(in Foo& foo) {}
 
 It's quite ugly and C-like, but that's the first thing that came
 to mind. The reference value is unique to the current method and
 shouldn't share the same storage qualifiers as it's referenced
 memory.

D is over - as nice as it would be to be able to fix the problem in the language, it would be too disruptive right now.

I think it would be better to fix it in D2 instead of patching a language design flaw with a template. It wouldn't be the first time D2 has changes that breaks existing code anyways (and the upcoming T[new] will definitely break a lot of code, so does shared when it works, etc), so it would be less disruptive to do it now than never do it.

I agree with the sentiment. The issue is, however, that the change adds a fair amount of complexity to the const system for an arguably not-often-used need. Andrei

Correct me if I'm wrong, but I don't see how complex that could be. I assume the compiler already makes the difference between the reference value and the referenced object, all that needs to be done is to reflect that view in the syntax. Maybe a .ref property? class A {} void foo(in A a) { a = new A(); // fail, cannot modify const a.ref = new A(); // ok, only reference value is modified } If you want to make the reference immutable, you can use the .ref on the class identifier: const(A.ref)[] AList; // slice of const references to A It may not be perfect, but I do firmly believe that the D syntax needs a mechanism to separate references from objects, even if rarely used, I can think of at least 15-20 places in my code I had to use workarounds for such cases. I don't think A* should be used since that is a pointer to an object reference, it would break too much code and be incredibly hard to track back. A& looks nice because that's how references are already handled in C++, and we'd get const(A)& the same way we get const(int)*.
Aug 31 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jeremie Pelletier wrote:
 Andrei Alexandrescu Wrote:
 
 Jeremie Pelletier wrote:
 Graham St Jack Wrote:

 On Sun, 30 Aug 2009 21:28:18 -0400, Jeremie Pelletier wrote:


 I agree that D lacks a mechanism to separate the object from it's
  reference. Maybe syntax like the following could be used to
 apply the storage class to the object value, and not the
 reference value:

 class Foo; void bar(in Foo& foo) {}

 It's quite ugly and C-like, but that's the first thing that came
 to mind. The reference value is unique to the current method and
 shouldn't share the same storage qualifiers as it's referenced
 memory.

D is over - as nice as it would be to be able to fix the problem in the language, it would be too disruptive right now.

language design flaw with a template. It wouldn't be the first time D2 has changes that breaks existing code anyways (and the upcoming T[new] will definitely break a lot of code, so does shared when it works, etc), so it would be less disruptive to do it now than never do it.

a fair amount of complexity to the const system for an arguably not-often-used need. Andrei

Correct me if I'm wrong, but I don't see how complex that could be. I assume the compiler already makes the difference between the reference value and the referenced object, all that needs to be done is to reflect that view in the syntax.

There was a lot of discussion around "head constness" and "tail constness" a while ago in this newsgroup. The general sentiment was that adding one or both of these nuances would make const too difficult to bother with.
 Maybe a .ref property?
 
 class A {}
 void foo(in A a) {
     a = new A(); // fail, cannot modify const
     a.ref = new A(); // ok, only reference value is modified
 }
 
 If you want to make the reference immutable, you can use the .ref on the class
identifier:
 
 const(A.ref)[] AList; // slice of const references to A
 
 It may not be perfect, but I do firmly believe that the D syntax needs a
mechanism to separate references from objects, even if rarely used, I can think
of at least 15-20 places in my code I had to use workarounds for such cases.
 
 I don't think A* should be used since that is a pointer to an object
reference, it would break too much code and be incredibly hard to track back.
A& looks nice because that's how references are already handled in C++, and
we'd  get const(A)& the same way we get const(int)*.

There would still be a problem with struct objects. Andrei
Aug 31 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Aug 2009 18:31:33 -0400, Graham St Jack  
<graham.stjack 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
Aug 31 2009
prev sibling next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 31 Aug 2009 09:12:33 -0400, Steven Schveighoffer wrote:

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

I remember the history - it was long and complicated, with no answer that looked good. I also agree that Rebindable as it stands needs work, and definitely needs to be a transparent wrapper. Since I don't understand the issues all that well, how about you submit the bug report?
Aug 31 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Graham St Jack 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?
 

Hi Graham, Could you please post a short snippet (or a few) that illustrate the problems you ran into with Rebindable? Thanks, Andrei
Aug 31 2009
parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 31 Aug 2009 15:20:21 -0500, Andrei Alexandrescu wrote:

 Graham St Jack 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?
 

Hi Graham, Could you please post a short snippet (or a few) that illustrate the problems you ran into with Rebindable? Thanks, Andrei

The code fragments are lost in the sands of time - I can recreate them if necessary, but here is an outline of what the problems were: Rebindable!(Foo) foo = null; foo = cast(immutable) new Foo(); // ok so far foo = Foo.init; // still ok if (foo !is null) {} // compiler error if (foo.get !is null) {} // another compiler error, and nasty! The main thing that has to change in Rebindable is that it needs to be a transparent wrapper, so that "if (foo !is null) {}" works. What I was doing to get into trouble was writing some communications code using Fibers, and I wanted the message objects to be immutable (call me silly, but I wanted to give it a go). This meant I needed to: * Have a templated queue class that could contain any sort of mutable types, and const or immutable objects. In particular, I didn't want the queue to have to use different code for objects and (say) integers. * Pass messages between the Fibre's stack frame and the main thread, so for an immutable object reference I needed to: test for null, assign to null and assign to a new message. The motivation for passing immutable messages around is that there is an implicit assumption that these messages don't mutate as they fan out to various destinations, and I wanted some compiler enforcement.
Sep 01 2009