On 11/11/2012 2:33 PM, Walter Bright wrote:
[...]
I've thought about using smart pointers for the CTFE stuff. I think that would resolve it.

I'm a little concerned that using smart pointers in general would cause slowdowns.

Well, if you have the choice between compiling small programs quickly, or compiling large programs at all, which do you think is the better choice for dmd?  And really, I think the performance hit is much smaller than you fear.  With decent inlining, dereference can be as cheap as native pointers, and reference counting only starts to get expensive if you need to support multi-threading.  Even then, by using raw pointers to indicate non-owning usage, you can avoid the vast majority of reference count changes.  And then, to make a fair comparison, you have to judge the result against 100% manual memory management (free() tends to be more expensive than malloc()).  I think you will find that smart pointers stack up pretty well (although I would not advocate a general-purpose one like shared_ptr<>...that's a bit heavyweight for dmd).

Another refactoring I'd like to see happen in dmd is that some of its data structures become copy-on-write, as many, many problems have been caused by changing things that someone else assumed wouldn't be changed.

And that job would be made a lot easier if all data were private to begin with. ;)  Again, a lot of these changes could be detected with some asserts at strategic locations (although, asserts cannot catch all mutations, obviously, which is why private data goes further).

When you say "some data structures", do you mean the Dsymbol hierarchy?  That seems to be a pretty major core of the front-end.  It would be great if that were immutable...I see a lot of methods which could probably be made const (in fact, 90% of the interface could be made const with no other change, I think).

Dave