On Tuesday, 17 November 2015 at 23:50:13 UTC, Timon Gehr wrote:
>> Main use case for such containers is efficient thread sharing and that
>> totally justifies specialized container (or even allocator) for each
>> dataset.
>
> Persistent containers are useful even if only a single thread is involved, as they can speed up some algorithms.
>
> Having the library provide List!T, but not List!(List!T) is a ridiculous situation. More generally, types shouldn't need to satisfy any additional constraints (beyond abstract container specific ones) to be allowed to place their instances in containers.

In my opinion it is perfectly reasonable to require GC for such "casual" usage and require narrow specialization from RC based solutions. Physical immutability requires external memory tracking - GC provides that naturally and trying to ignore that fact with RC model feels like cheating yourself to me.

It may be possible to provide more generic solution if you place reference counting into allocator itself. But I trust Andrei expertise in this domain so if he decided to not pursue this approach there must be good reasons.

> I don't think the cases where writing a new specialized version from scratch is justified are what the new container module will be about.

Yes, indeed. That is why I don't think non-GC version of such containers belongs to such standard package at all. It is not worth the proposed costs.

On Sunday, 22 November 2015 at 00:38:19 UTC, Dicebot wrote:
> In my opinion it is perfectly reasonable to require GC for such "casual" usage and require narrow specialization from RC based solutions. Physical immutability requires external memory tracking - GC provides that naturally and trying to ignore that fact with RC model feels like cheating yourself to me.

On a related topic - are there any pure functional languages that don't use GC internally? Those could be worth looking at.

On 11/21/2015 07:48 PM, Dicebot wrote:
> On Sunday, 22 November 2015 at 00:38:19 UTC, Dicebot wrote:
>> In my opinion it is perfectly reasonable to require GC for such
>> "casual" usage and require narrow specialization from RC based
>> solutions. Physical immutability requires external memory tracking -
>> GC provides that naturally and trying to ignore that fact with RC
>> model feels like cheating yourself to me.
>
> On a related topic - are there any pure functional languages that don't
> use GC internally? Those could be worth looking at.

I don't know of any, but that's beside the point. RC can be integrated with purity relatively easily if it's done automatically by the compiler. The problem is library-level RC does not work with immutability. -- Andrei

On Sunday, 22 November 2015 at 15:25:28 UTC, Andrei Alexandrescu wrote:
> I don't know of any, but that's beside the point. RC can be integrated with purity relatively easily if it's done automatically by the compiler. The problem is library-level RC does not work with immutability. -- Andrei

Not entirely. If there are any one can have a look how compiler organizes rc management internally there and what are current D limitations of doing so in a library. But I don't know any either and suspect it isn't coincidental.

On Monday, 23 November 2015 at 04:40:08 UTC, Dicebot wrote:
> Not entirely. If there are any one can have a look how compiler organizes rc management internally there and what are current D limitations of doing so in a library. But I don't know any either and suspect it isn't coincidental.

They exist:

1. reactive programming language that don't do allocation

2. languages that forbid circular references

3. languages that allow memory leaks in the case of circular references

In addition you have runtimes that use region allocators.

However, keep in mind that mark-sweep was invented for Lisp.