RFC: std.json sucessor

[Walter Bright via Digitalmars-d]

On 8/22/2014 11:25 PM, Ola Fosheim Gr wrote:
> On Saturday, 23 August 2014 at 05:28:55 UTC, Walter Bright wrote:
>> On 8/22/2014 9:48 PM, Ola Fosheim Gr wrote:
>>> On Saturday, 23 August 2014 at 04:36:34 UTC, Walter Bright wrote:
>>>> On 8/22/2014 9:01 PM, Ola Fosheim Gr wrote:
>>>>> Does this mean that D is getting resizable stack allocations in lower stack
>>>>> frames? That has a lot of implications for code gen.
>>>>
>>>> scopebuffer does not require resizeable stack allocations.
>>>
>>> So you cannot use the stack for resizable allocations.
>>
>> Please, take a look at how scopebuffer works.
>
> I have? It requires an upperbound to stay on the stack, that creates a big hole
> in the stack. I don't think wasting the stack or moving to the heap is a nice
> predictable solution. It would be better to just have a couple of regions that
> do "reverse" stack allocations, but the most efficient solution is the one I
> outlined.

Scopebuffer is extensively used in Warp, and works very well. The "hole" in the 
stack is not a significant problem.


> With json you might be able to create an upperbound of say 4-8 times the size of
> the source iff you know the file size. You don't if you are streaming.
>
> (scopebuffer is too unpredictable for real time, a pure stack solution is
> predictable)

You can always implement your own buffering system and pass it in - that's the 
point, it's under user control.