Arthur O'Dwyer

I'll do `map_error` and `or_else` also; just poking the CI. This depends on (i.e., is a superset of) #99.

This incidentally simplifies the preprocessor stuff, by making these codepaths look the same in both C++11 and C++14. The old code had the weird effect that the C++11 codepath was...

Note that `or_else::[extensions.or_else]` still has an unused variable: auto failptr = [](eptr e) { return tl::expected(tl::unexpect, std::move(e));}; but I didn't remove it because it looks like it probably indicates some...

Support physical memory hack ("magic ring buffer")

1

Alex Rosenberg suggests that no "STL ring-buffer" will replace the most efficient real-world ring-buffer unless it supports the following performance hack: Let's back our particular `ring_view` by a span of...

Starting with 8e20e1ee, after broker goes down and back up, `rd_kafka_destroy` of groupconsumer hangs

12

I'm pulling this out into a new Issue, because we keep discussing it in different random PRs/issues and it'll help to have just one place to discuss it. On #4667...

Revert 8e20e1ee (#4117) to fix hang in destruction of groupconsumer

1

We observed that destroying a groupconsumer would often hang waiting for the broker thread to exit. We tediously bisected the problem to the specific commit 8e20e1ee (the last commit before...

vector::assign is incorrectly gated on is_trivially_relocatable

26

I noticed that you have at least two places where a memcpy optimization is gated only by your `is_trivially_relocatable_v` trait, even though the operation being optimized is a _copy construction_,...

Order the arguments of pointer_in_range

6

Semantically ordered arguments should be lexically ordered, too. See https://quuxplusone.github.io/blog/2021/05/05/its-clamping-time/ I feel _very_ strongly that the arguments to `pointer_in_range` — like the arguments to `rotate` and so on (with the...

Feature request: Make `static_vector` "trivially relocatable" when possible

3

It was recently discussed on [the cpplang Slack](https://cpplang.slack.com/archives/C2PQKRWJU/p1699903321902899) that Boost implements a lot of class types that are "Platonically trivially relocatable" without being _known to the compiler_ to be trivially...

This PR definitely isn't ready for prime time, but I figured I might as well exploit Cunningham's Law here. The idea is that when the compiler supports `__cpp_impl_trivially_relocatable` (P1144's proposed...