D Ranges

[Jonathan M Davis]

On Sunday, September 15, 2013 10:39:40 monarch_dodra wrote:
> I have a few issues with ref counted.
> 
> First, if you *ever* place one in an array or an AA, then you
> will leak. It is NOT designed for simply incorporating reference,
> but for deterministic finalization.
> 
> Second, it has an elaborate postblit and opAssign. This is not a
> big issue in itself, but their sole existence does cause dmd to
> generate code that is sub-optimal. It also means it can't take
> the "optimal" route in a lot of algorithms (array has to emplace
> each element individually, for example).
> 
> Finally, a RefCounted will implicitly cast to its payload. I
> think this is *horrible*. Before you know it, the Payload will
> have "jettisoned" its wrapper, and you'll be operating on your
> value-type payload "raw". For example:
> void foo(T t);
> RefCounted!T myRecCounted;
> foo(myRefCounted); //Passes. Oops!
> 
> The workaround would be to either require explicit "get" to go
> from ref counted to payload (breaking existing code), or to
> entirelly wrap the RefCounted as a member inside the struct
> (requires boilerplate code).

Yeah. RefCounted could/should definitely be improved, but the concept is 
essentially the same as smart_ptr in C++11. In many ways, smart pointers are 
far superior to using the GC, and I really think that we should do a better 
job of supporting them and promoting them. There are obviously plenty of cases 
where the GC is better or even necessary, but in many cases - particularly 
with objects - smart pointers are arguably a much better way to go.

- Jonathan M Davis