RFC: moving forward with @nogc Phobos

[Dicebot via Digitalmars-d]

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.

>
>> 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.