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