On Thu, Aug 13, 2020 at 8:56 AM Inbal Levi via SG14 <sg14_at_[hidden]>
wrote:

> Thanks very much Ben, Staffan. Just a small clarification for ring buffer
> update:
> Inbal: Technical difficulties with ring buffer meeting yesterday.
> Gathering the various inputs for the ring buffer. One option is to propose
> some ring buffer (P0059) abilities to P1958 and P0260. Use cases are
> welcome, so that we can decide if expanding P1958 is worthwhile. Jens
> suggested a use case for a ring span, I have formed an initial API and
> hoping to have his feedback on it.
>

My experience from P0059 is that anything we do for "ring buffer" should
start from use cases, by which I mean *sample code collected from the wild*
.

- People are remarkably awful at describing their use-cases in English.
- People are remarkably awful at estimating whether a given API will work
for their use-case.

IMO the only thing that works is "Committee-aided refactoring": look at how
their actual code is actually physically written today, and then *show* how
it could be rewritten in terms of a proposed new API while still
accomplishing the same job.

If this project stalls for lack of real-world code samples, then maybe the
problem isn't such an important one after all. (That was the impression I
was left with after P0059.) Or rather, maybe there is no "the" problem;
maybe there are many different use-cases with incompatible requirements
(generic, thread-safe, non-owning, fast, MPMC, SPSC,...) and also different
usage patterns (so there's not even any point in trying to define a
"concept" or "interface" that all instantiations might satisfy).

my $.02,
–Arthur