Formal review of std.buffer.scopebuffer

Walter Bright newshound2 at digitalmars.com
Tue Mar 18 14:50:41 PDT 2014


On 3/18/2014 4:24 AM, Dicebot wrote:
> I was among those who has been continuously asking for cleaning Phobos
> allocations and I feel  that this modules about zero of issues I see. API
> allocations are much more important to fix than internal allocations and you
> still have not answered why you consider scopebuffer of more priority.

We can fix all the internal allocations without changing APIs and without any 
user disruption. This is low hanging fruit. Fixing external allocations will 
take longer and will have to be more carefully done.


> Also while it is important it is not at any hurry and shouldn't be done hastily
> simply because it is next discussion topic of the month.

Yes, it is important to not unnecessarily procrastinate on this. There are 
windows of opportunity for us. Moving the start of the window does not extend 
the end of it - it just means a shorter window of opportunity.

Every day counts. Schedules slip one day at a time. We lose momentum every time 
there's a long Reddit thread about GC problems. We cannot afford this. Although 
the 2 month review of ScopeBuffer is far from hasty, we can be hasty about 
internal non-user-visible changes to Phobos because those can be easily backed 
out if they prove unworthy.

There is nobody working on this besides me, other than the people working on 
@nogc. (if I'm wrong, let me know). It's a high priority problem. I'm ok for me 
doing the work, but I ask for everyone's support in getting this done.

---

In general, many issues with external GC allocations in Phobos can be resolved 
by changing the API so that the output goes to an OutputRange. std.string is a 
prime example of a module that needs to be range-ified. Any help with this would 
be important and appreciated. I know there are a couple people working on this 
with std.file, but there's plenty more needed.

(For legacy compatibility, the old APIs must remain. I do not propose breaking 
existing code. But the old APIs can be redone as wrappers around the range 
versions.)


More information about the Digitalmars-d mailing list