On Mon, 29 Nov 2010 13:06:17 -0500, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:

On 11/29/10 10:24 AM, Steven Schveighoffer wrote:
This only solves the caching issue (which I agree is a large issue).
There are other cases where you want a mutable pointer to other data
that the object does not own. Such as a widget having a pointer to its
window. Assuming that window draw routines need to be non-const, a
widget cannot draw itself. You need to keep the widget to window
relationship outside the class, or cast. Both of these solutions are
awkward at best.

Would Rebindable help that situation?

No, the issue is not one of rebinding, it's that you want to call a non-const function (drawLine, etc on the window) while drawing a widget (which is not likely to change the state of the widget). In essence, the pointer to the window that the widget contains is an association, not an ownership. But because const is transitive (not a bad thing in most cases), the compiler assumes you want to protect that reference as well.

I recall I managed to convince Walter that the system works, but we
agreed it would cost too much for what it does. I think it can be
implemented as a library artifact under certain assumptions.

It would be nice to have user-defined annotations, so we could play with
possible implementations. As I recall, the acceptance of annotations in
D had not occurred when logical const was last discussed, and this seems
like a perfect candidate for annotations.

Absent annotations, would a parameterized type suffice?

Most likely not. How do you say that the 'draw' function switches the widget to a different parameterized type? With const, you can just slap a const on the end of the function.

Here is some example of what I mean:

class Widget
{
   mutable Window location;
   int x, y, width, height;
   void draw() const { location.drawRectangle(x, y, width, height); }
}

where Window.drawRectangle is not a const function.

-Steve

Reply via email to