Klemens Morgenstern wrote:
The dynamic_buffer concept comes from asio and I don't think it is needed in a coroutine library. It's one of the "asio did it" features. ... It seems yet another design decision based on "asio did it" that doesn't seem to have reevaluated the changed conditions. ...
I find myself agreeing with Klemens's general point. There are things in Capy that are copy-pasted from Beast, copy-pasted from cppalliance/buffers, copy-pasted from "Asio has them so we need them too." We have the opportunity to start from a clean slate and only add things on an as-needed basis, with rationale why we added them. And the above three reasons are not that. Capy needs to be foundational but minimal, with each feature there having strong justification for existing in Capy (rather than somewhere else.) Some of the components already meet this condition, others not. What makes this important now, rather than merely a theoretical nitpick, is that once things are released to the world (as part of a Boost release), it becomes hard to take them away. Whereas if we don't ship something now, and then it turns out that we should have done so, we can add it in a later release very easily. So our initial Capy needs to be as small as possible.