Ivan Zhakov wrote: > As far I remember this thread about two pools paradigm itself > (result_pool and scratch_pool). It's not about making all functions > follow two pools paradigm.
Correct. > Some of API introduced in 1.9 doesn't > follow this paradigm for some reason. Yes, I see that. > Please understand me correctly: > I really like two pool paradigm, but sometimes it's not necessary, > especially for local helpers. OK, you have partially convinced me. For a simple local function, we might not want to take two pools when that seems unnecessarily verbose. If this function takes one pool, allocates its result in that pool, and perhaps allocates a small amount of temporary data as well, I accept your argument that we don't necessarily want to name the pool 'result_pool' because that could be confusing in places where its implementation is storing scratch data. In cases like this I agree we may want to use the name 'pool'. And in other cases there is flexibility too. We don't enforce a rigid rule. - Julian
