const challenge

[Jason House]

Steven Schveighoffer Wrote:
> I believe that there is always a way to redesign your thinking to have const 
> work.  If you have a const widget and need to have it draw itself, pass in 
> the non-const values needed to do the drawing.  Or if you absolutely have to 
> have a structure with a draw routine that doesn't take the argument of the 
> thing to draw it on, then create a wrapper structure that isn't const but 
> contains the const widget.  Or change your widget so the data you want to 
> remain const is declared const.  It's hard to speculate without seeing the 
> actual code, but I believe it's possible to solve.

That's the whole point of my challenge.  I'd like to see people post their real code and have others tack a whack at redesigning them.  Maybe we'll see it's easy and there's a general method that should go into an FAQ.  Or maybe there's a few corner cases that are tough to solve.  Either way, we're smarter about the pros and cons of our (now stable?) const design.



> I think the transitive const debate has died down.  I still believe the 
> head-const debate is very much alive, and I'm prepared to argue my side if 
> anyone should challenge that validity.  Last I checked, nobody had refuted 
> my points that head-const for a class was possible and useful :)

What I have nagging me in the back of my mind is if there should be ways to break transitive const with an instance of head const... such as access to a logging utility, a raster for drawing images, etc...  I would like to put that to rest.  All my current coding is in D 1.x.  I'd love to see active (C++?) const coders to post problematic cases.  In the end, I'd like to see a final blessing of D's const and have stuff like Tango finally start using it (so I can then port my code that depends on Tango to D 2.x)