What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 10/9/14, 9:27 AM, Johannes Pfau wrote:
> 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.

Yes, that's accurate. Thanks! -- Andrei