== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > On 8/27/10 7:44 PDT, Pillsy wrote: > > dsimcha Wrote: > > [...] > >> I'd like any comments anyone might have on to what extent > >> arbitrarily expensive postblits should be considered in the > >> design of Phobos. > > > > I agree with you: expensive post-blits just don't seem sufficiently > > necessary in D to warp the design of the standard library around > > them, and have a distinctly anti-patternish feel to them. You have > > too many other options, like straight reference semantics, copy-on- > > write, and (with immutability and GC) safely shared structure. > > > > The last can be an incredibly useful technique for reducing the > > cost of copying, because it allows you to treat an immutable > > reference type exactly like a value type. > > > > Cheers, > > Pillsy > Clearly immutable sharing helps, and clearly reference counting and COW > are valid techniques. However, the situation is not as cut and dried. > The problem with RC/COW is that they reduce exception safety essentially > _everywhere_ else but the copy constructor. Once you have a type using > RC/COW, any mutation of that object, even one that ostensibly doesn't > cause resource allocation, might have arbitrary cost or fail. This was > the experience with std::string in C++ - its creators did everything > they could to enable reference counting, and the outcome was quite > unpleasant. > Add to this the implementation annoyance of checking for aliasing in > _every_ single method of the type. RefCounted in phobos can help with > that, but not without a cost. > So I'm not sure it's as simple a decision as it might sound. > Andrei
But with RC/COW at least you know that if something becomes arbitrarily expensive it's for a good reason, i.e. because doing anything else would break the abstraction you're trying to create **right now**. With eager copying copies get made very often when a human reader reasoning only locally about the code could easily prove they're not needed. Furthermore, I think my point still generally holds about reference vs. value semantics: When you have to bend over backwards to get value semantics, they're no longer easier to reason about.