I would guess not, but I wouldn't bet on it. ;)
And thanks a lot for your input, Arthur.

On Fri, 14 Aug 2020 at 11:42, Guy Cpp via SG14 <sg14_at_[hidden]>
wrote:

> Yup, I have to agree. Use cases drive library adoption. Linear algebra
> started with an assessment of what's already happening in that space.
>
> I wonder if there is a ring buffer "concept" waiting to be described...?
>
> (joke)
>
> Cheers,
> G
>
> On Thu, 13 Aug 2020 at 16:07, Arthur O'Dwyer via SG14 <
> sg14_at_[hidden]> wrote:
>
>> 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
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>