What are the worst parts of D?

[Johannes Pfau via Digitalmars-d]

Am Thu, 09 Oct 2014 15:57:15 +0000
schrieb "Dicebot" <public at dicebot.lv>:

> > Unfortunately it doesn't. RC does. Lazy computation relies on 
> > escaping ranges all over the place (i.e. as fields inside 
> > structs implementing the lazy computation). If there's no way 
> > to track those many tidbits, resources cannot be reclaimed 
> > timely.  
> 
> Are you trying to tell me programs I work with do not exist? :)
> 
> Usage of output range is simply a generalization of out array 
> parameter used in both Tango and our code. It is _already_ proved 
> to work for our cases. Usage of input ranges is less important 
> but it fits existing Phobos style better.
> 
> We also don't usually reclaim resources. Out application usually 
> work by growing constant amount of buffers to the point where 
> they can handle routine workload and staying there will almost 0 
> GC activity.
> 
> I don't understand statement about storing the ranges. The way I 
> have it in mind ranges are tool for algorithm composition. Once 
> you want to store it as a struct field you force range evaluation 
> via output range and store resulting allocated buffer. In user 
> code.

I think Andrei means at some point you have to 'store the range' or
create an (often dynamic) array from the range and then you still need
some sort of memory management.

Ultimately you still need some sort of memory management there and RC
will be nice for that if you don't want to use the GC. You can also
store the range to a stack buffer or use manual memory management. But
ranges alone do not solve this problem and forcing everyone to do
manual memory management is not a good replacement for GC, so we need
the discussed RC scheme. At least this is how I understood Andrei's
point.