RFC: moving forward with @nogc Phobos

[Andrei Alexandrescu via Digitalmars-d]

On 9/29/14, 8:53 AM, Dicebot wrote:
> On Monday, 29 September 2014 at 15:18:40 UTC, Andrei Alexandrescu wrote:
>> On 9/29/14, 5:29 AM, Dicebot wrote:
>>> Any assumption that library code can go away with some set of
>>> pre-defined allocation strategies is crap. This whole discussion was
>>> about how important it is to move allocation decisions to user code
>>> (ranges are just one tool to achieve that, Don has been presenting
>>> examples of how we do that with plain arrays in DConf 2014 talk).
>>
>> That's making exactly the confusion I was - that memory allocation
>> strategy is the same as memory management strategy.
>
> Yes but neither decision belongs to library code except for very rare
> cases.

You just assert it, so all I can say is "I understand you believe this". 
I've motivated my argument. You may want to do the same for yours.

>>> In that regard allocators + ranges are still the way to go in my
>>> opinion. Yes, sometimes those result in very hard to use API - providing
>>> GC-heavy but friendly alternatives for those shouldn't do any harm. But
>>> in general full decoupling of algorithms from allocations is necessary.
>>> If that makes D poor cousin of C++ we may have a learn few tricks
>>> from C++.
>>
>> As long as things are trivial they can be done with relative ease,
>> albeit with more pain. But consider e.g. the recent JSON library by
>> Sönke. It needs to create a lookup data structure and return things
>> like strings from it. What primitives do you think could it define?
>
> Sounds like it may have to define own kind of allocator with certain
> implementation restrictions (and implement it in terms of GC by
> default). I have not actually read the code for that proposal so hard to
> guess. Will need to do it if it really matters.

So you don't have an answer. And again you are confusing memory 
allocation with memory management.

I have sketched an approach that works and will take us to Phobos being 
most transparently usable with tracing collection or with reference 
counting. Part of that is RCString (and generally reference counted 
slices and hashtables), and another part is the @refcounted attribute 
for classes. I will push it through. If you have any objections, it 
would be great if you argued them properly.


Thanks,

Andrei