- Boost - lists.boost.org

Fwd: [release] 1.92.0 post-beta merges: master branch is open
by René Ferdinand Rivera Morell 18 Jul '26

18 Jul '26

Failed to send this to the correct reply email.. ---------- Forwarded message --------- From: René Ferdinand Rivera Morell <grafikrobot(a)gmail.com> Date: Tue, Jul 14, 2026 at 10:29 AM Subject: Re: [release] 1.92.0 post-beta merges: master branch is open To: Ion Gaztañaga <igaztanaga(a)gmail.com> On Tue, Jul 14, 2026 at 10:26 AM Ion Gaztañaga <igaztanaga(a)gmail.com> wrote: > El 14/07/2026 a las 17:19, Ion Gaztañaga via Boost escribió: > > El 14/07/2026 a las 16:18, René Ferdinand Rivera Morell via Boost > escribió: > >> Can I merge the latest B2 version 5.5.2? Changes in it from the current > >> 5.5.1 are https://github.com/bfgroup/b2/releases/tag/5.5.2 > > > > Go ahead as this fixes a regression. > > > > Ion > > Sorry, I misunderstood the regression issue, but 5.5.2 fixes other issues. > Rene, > are you going to fix the regression and create 5.5.3 before merging? > Yes, going to fix the issue Alexander mentioned and make a 5.5.3. I'll ask again after I have the new patch release tested, published, merged to develop, and ready for master. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

2 3

Capy/Corosio Review Extended to Sunday July 11
by Jeff Garland 16 Jul '26

16 Jul '26

Hi Everyone - I appreciate all the reviews up to now, but as previously mentioned there's a lot of surface area to cover -- so we'll be extending the review for a few more days. Thanks again, Jeff

1 1

[release] Boost 1.92.0 Beta 1 Release Candidate 1 is available
by Ion Gaztañaga 12 Jul '26

12 Jul '26

Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/> The SHA256 checksums are as follows: 11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2 585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz 290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z 005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

8 16

Boost Review for Capy and Corosio - June 23 to July 7th
by Jeff Garland 09 Jul '26

09 Jul '26

Dear Boost Community: The Boost Formal Review of the *Corosio* and *Capy* libraries will begin on *June 23, 2026* and will conclude on *July 7, 2026*. I'm Jeff Garland and I'll be the review manager. I'd like to thank Vinnie for inviting me to maintain the continuity from Boost.Asio and I'll apologize now for the late notice. Since this is a two library review the period is somewhat extended from normal. In fact my personal pre-review indicates we will likely need an extension due to the size of the libraries -- I'll work with the review wizards on that. Capy Capy is a coroutine foundation library providing task types, execution contexts, executors, asynchronous synchronization primitives, buffer abstractions, and coroutine composition facilities. It serves as the execution and asynchronous programming substrate upon which Corosio is built. Repository: - Capy GitHub Repository <https://github.com/cppalliance/capy?utm_source=chatgpt.com> - docs <https://develop.capy.cpp.al/capy/index.html> Corosio Corosio is a coroutine-native asynchronous I/O library for C++20. It provides networking and I/O facilities designed specifically for coroutines, with awaitable operations, executor affinity, cancellation support, and cross-platform implementations based on IOCP, epoll, and kqueue. Repository: - Corosio GitHub Repository <https://github.com/cppalliance/corosio?utm_source=chatgpt.com> - docs <https://develop.corosio.cpp.al/corosio/index.html> Review Questions Potential reviewers are encouraged to consider the following questions: 1. What is your evaluation of the usefulness of the libraries? 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. Have you used either or both libraries? What was your experience? 6. Are the libraries ready for inclusion in Boost? 7. If not, what changes would you recommend before acceptance? 8. Do the libraries fit well within the existing Boost ecosystem? 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed? How to Participate Please post your review to the Boost Developers mailing list. Reviews from both experienced Boost contributors and first-time reviewers are encouraged. Reports based on real-world usage, experimentation, code inspection, and documentation review are all valuable contributions. At the conclusion of the review period, the review manager will consider all feedback and determine whether the libraries should be accepted into Boost. We look forward to your participation in this review.

19 72

[release] 1.92.0 closed for Beta
by Ion Gaztañaga 09 Jul '26

09 Jul '26

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: https://github.com/boostorg/website-v2-docs/blob/develop/release-notes/boos… Calendar is here: https://www.boost.org/calendar/ Thanks, -- The Boost Release Team

1 0

[icl] Request to merge PR#54
by Joaquin M López Muñoz 08 Jul '26

08 Jul '26

Hi, In its version 22, libc++ introduced changes to their implementation of non-heterogeneous lookup for associative containers that break some assumptions Boost.ICL relies on: https://github.com/llvm/llvm-project/issues/183189 Turns out lookup for associative containers has been poorly specified since forever. I submitted an issue to the WG21 committee positing that a resolution should be adopted that (among other things) would make Boost.ICL assumptions correct: https://cplusplus.github.io/LWG/issue4572 In the latest meeting in Brno, however, the committee decided against that resolution with the result that, pending an upcoming reformulation of the affected part of the standard, Boost.ICL will be officially relying on undefined behavior. I've written a PR to circumvent this problem: https://github.com/boostorg/icl/pull/54 that relies on heterogeneous lookup (well defined and compatible with the asumptions made by Boost.ICL). I contacted the library maintainer some weeks ago but received no answer, so I'm asking here for this PR to be merged before Boost 1.92, since without it, Boost.ICL is currently broken for libc++ v22. FWIW, some users of Boost.ICL are already applying this fix to their local deployments of Boost: https://github.com/azahar-emu/ext-boost/commit/6a85c3100499e886e11c87a5c210… Another contributor has posted a different PR with the same goal: https://github.com/boostorg/icl/pull/57 My analisys is that this PR is not as comprehensive as PR#54 (it fails to cover intervals of type right_open_interval and related), plus its performance is probably slightly inferior, so I still recommend that PR#54 be used instead. Thank you, Joaquín M López Muñoz

3 4

[capy] Andrzej's feedback
by Andrzej Krzemienski 08 Jul '26

08 Jul '26

Hi Everyone, I do not feel qualified in the domain of asynchronous I/O to provide a responsible review. But let me share some observations instead. I would like to thank the Capy/Corosio team for developing and sharing these libraries. This is a huge scope, a huge effort, a great lot of moving parts and details to tackle. I am not even sure how this can be reviewed with the level of scrutiny that is required. I appreciate the unprecedented level of the design rationale. The library comes not only with sources, tests and library documentation, but also with lots of documents presenting rationale for every tiny decision. The contribution of this library is not only the code that users can use, but also the accumulated (and shared) knowledge that can be used by anyone, for writing their own I/O framework and avoiding the past mistakes. This alone builds my trust in the authors and the quality of the library. The value proposition of Capy and Corosio is not only in providing a faster and easier to use alternative to ASIO. It is also the responsiveness of the authors and openness for contribution. It gives me confidence that if I encounter some problems with the library in the future, they will be solved in a predictable way. Now, the concerns. A couple of things in the IoAwaitable protocol give discomfort: 1. Having to use thread_local storage 2. Having to use the double-call syntax. 3. Having to use pass they stop_token via await_ready (and therefore risk UB when stop_token is queried before the first suspend). Ideally, these things should not be present in a protocol. However, it seems impossible to provide any alternative design, with coroutines as its basic vehicle, that would have fewer problems like these. What can we conclude from this? It looks like C++ coroutines are not well suited for I/O-like flows with environment propagation. You can do it *somehow*: just pass all you need in the coroutine's function parameter list, but it is not ergonomic or type-safe. I think the review of Capy may be exposing a design flaw in coroutines. If the goal of Capy is to provide the best third-party library asynchronous-I/O coroutine implementation, then the current design may indeed be the best (as in "no better design can be thought of"). But if the goal is to aim at standardization, I do not think that such unsafe design would work. The action would rather be, "fix coroutines in the language". This makes me think that coroutines in C++ may be a dead end. This would be consistent with some other observations: scarce adoption in the community and WG21 itself choosing to use a different model for asynchronous flows. One could question one design choice in Capy: why go with coroutines when you have to fight an uphill battle with the language? But then, given that it outperforms ASIO and std::execution, it has clearly earned its place. It surely deserves its place in Boost as "the best you can do with coroutines for I/O". But if I were to consider switching to a different library for async I/O I would also consider/evaluate non-coroutine alternatives. On the usage of error_code and reporting failures. The library doesn't give me a clear picture on how it handles and how I should handle the non-clear-sky situations. For things that represent obvious disappointments -- broken connection, problems on the wire, not enough memory to process a request -- it sometimes returns an error_code and sometimes throws an exception. It looks like the division is: * for things happening on the wire, or in the system's native part of the I/O implementation, use error_code * for problems with resources in the implementation of the library throw exceptions. But then also, the library returns error_codes for situations that are not errors by any measure: for situations that I desire: * Successfully receiving full stream content. * Stopping the running process upon my request. The only model for this that I can adapt is that the contract of stream interaction is similar to the interaction with a human postman: * They can deliver you a parcel * But they can also tell you "I lost your parcel", or "while obtaining the parcel I noticed that the box is half-open", or "I had a car accident, and couldn't deliver your parcel" That is, your success is having had a meeting with the postman and chatted with them and maybe also having obtained the parcel. In that model not receiving a parcel is not an error. This makes sense for the interaction with a single stream, but breaks for the next layer: 1. when you have to interact with two streams at once: pull_from, push_to. 2. when you have "algorithms" such as when_any, when you have to nominate the first successful task. But in the postman model nearly everything is successful. Having read the stream status is success. In the case of push_to/pull_from, you might be interested in knowing which of the two streams was the cause of disappointment. But the interface does not let you get this information. Interaction with two postmen would require two statuses. While the contract of `stream.read_some` is "I promise you nothing else than to inform you what happened", it is not clear to me what the contract of pull_from is. Is it: a) I promise to pump the data from one stream to the other. We will call it a contract violation if I fail. OR b) I will just issue some stream instructions in sequence and tell you what the readouts of controls are. My having told you the readout is already a success; you interpret what this means for you. In this case I do not buy the "ASIO got that right" argument. If ASIO is also unclear about the contract, then ASIO got that wrong also. There are a lot of libraries that are popular, contribute to the success of servers that employ them, but that get their contracts wrong. I am bringing the contract aspect, because I know that the authors of Capy care deeply about this level of clarity. A number of libraries were accepted to Boost while having a muddy contract, and this did not seem to be a show-stopper. My observations are based on reading the documentation and the implementation of some parts of Capy and Corosio, running toy examples and discussing the design aspects with the authors. Disclaimer: I am affiliated with the C++ Alliance, and have occasionally contributed to Capy. Regards, &rzej;

7 15

Master branch closes for the 1.92 beta TOMORROW
by Ion Gaztañaga 07 Jul '26

07 Jul '26

Calendar is here: https://www.boost.org/calendar/ — The release managers

1 0

[Capy review] Beyond I/O
by Mateusz Fila 06 Jul '26

06 Jul '26

This review is focused on Boost.Capy and does not cover Boost.Corosio. It is based on approximately three months of experimentation with Capy in an R&D project on improving support for asynchronous operations in experimental high-energy physics data-processing application frameworks. That work was focused on asynchronous GPU operations in a multithreaded execution environment, including coordination with CUDA execution, rather than network or file I/O. As a result, only the generic asynchronous execution facilities provided by Capy were exercised. In particular, I did not use or evaluate the library's I/O-specific components. For the record, I am not associated with the authors or the C++ Alliance. 1. What is your evaluation of the usefulness of the libraries? I find this library highly useful, as it attempts to address a missing piece in the current C++ ecosystem. While C++20 introduced language support for coroutines, it intentionally didn't include an async library. As a result, the ecosystem still lacks a widely adopted, generic mechanism for representing asynchronous operations that can be communicated across library boundaries and composed between independent libraries. Earlier coroutine libraries such as concurrencpp, cppcoro, libcoro helped explore this design space, but most focused on particular use cases or specific aspects of asynchronous programming rather than defining a general, interoperable contract. Capy builds on those experiences and presents a cohesive design that I believe has the potential to become a common foundation for coroutine-based libraries. In particular, this is a library I wished existed so that when I want to use coroutines, I can rely on a reasonable foundation with some interoperability possible. Beyond the core abstractions and protocols, the library adopts a "batteries included" approach, providing an executor, synchronization primitives, and structured concurrency facilities, making it immediately useful for experimentation and real applications. 2. What is your evaluation of the design? The core of the library consists of the IoAwaitable protocol, executors, and facilities for launching asynchronous operations. On top of that are synchronization primitives based on suspension, facilities for structured concurrency such as when_all, and I/O support classes such as buffers and streams. I find this organization compelling, as it exposes useful building blocks without overly bloating the core library, making it a solid foundation for higher-level libraries implementing specific asynchronous operations and protocols. A similar separation between tasks, execution/scheduler, and context is also observed in other async and coroutine libraries. The core design appears sound and well documented. It addresses key concerns for a coroutine library, including the propagation of allocators, execution environment, and cancellation support. The protocol enables composition of tasks and supports implementing custom coroutine types, awaitables, and executors, as well as building adapters for types originating from other coroutine libraries. Due to the nature of coroutines, interoperability between different coroutine libraries is inherently limited. The advantage of Capy is that it clearly defines and documents its design and protocol making it easier to build an adapter. The protocol does not restrict the kinds of handlers that can be used in awaitables, so common strategies such as callbacks or polling can be implemented. The library is also not tied to a particular executor type, allowing custom executors to be integrated as well, including wrappers that submit work to thread pools already present in an application. One aspect the design handles particularly well is the explicit distinction between two continuation modes: continuation on the same execution resource, which can avoid unnecessary overhead, and rescheduling onto another execution context, for example by enqueuing the continuation. In Capy, both models are available, and authors of custom awaitables can explicitly choose the appropriate behavior without workarounds. 3. What is your evaluation of the implementation? I did not investigate the implementation of the I/O classes such as streams and buffers. For the remaining parts, the code is readable and appears to be of good quality. The authors are consistent with the overall design and avoid common problems such as unnecessary suspensions to query the execution environment from within a coroutine. The use of `thread_local` storage in the plumbing of allocators may initially raise concerns; however, its usage appears to be justified and well isolated. The library was used in a multithreaded application where tasks may resume on different threads without any observed issues. In a test setup involving multiple executors, all continuations were executed on the expected execution resources, and nothing appeared to escape the intended execution context. Exception propagation across awaitables and tasks works as expected; in the application I used, the overhead on the optimistic path was negligible. I did not exercise cancellation beyond simple examples, but it also appears to be viable based on the available interfaces and observed behavior. The library does exhibit the usual challenges related to the lifetime of objects captured by coroutines, although this is not specific to Capy and is explicitly addressed in the documentation. The library appears to depend primarily on standard C++, with only a few platform-specific workarounds for compatibility. It compiled without issues on Linux with GCC 14, 15, and 16, as well as Clang 19 and 22, in both C++20 and C++23. One very pedantic thing I spotted, in a few places, `static_assert(sizeof(A) == 0,` is used to invalidate remaining branches in `if constexpr`, which in practice compiles but isn't legit, see P2593. 4. What is your evaluation of the documentation? I found the documentation to be of high quality and mostly up-to-date, in some places maybe a bit too verbose. It clearly explains the API, provides comprehensive user guides and tutorials, and also includes the rationale behind the design decisions as well as comparisons with other libraries from the domain. I found it very helpful while working with the library and referred to it when needed. In particular it appears to be enough get a grasp of the core concepts and start writing custom awaitables and executors. The documentation also includes introductory chapters on coroutines, concurrency, and parallelism. I do not have a strong opinion on whether this is the best place for such an overview. One aspect I found somewhat concerning is the introduction of `thread_local` storage together with suggested use cases. This may not be appropriate guidance for newcomers, as correct usage of `thread_local`, particularly in asynchronous contexts, is error-prone. One improvement I would suggest is adding a search function, as I occasionally struggled to locate specific information when I couldn't remember which page contained the section I was looking for. 5. Have you used either or both libraries? What was your experience? I did not use Corosio. I did, however, use Capy in an R&D project, where I ported a CUDA-based variant of a high-energy physics particle track reconstruction library with GPUs algorithms and compared it against other ports based on stdexec, Boost.Fiber, and TBB-based suspension. https://github.com/cern-nextgen/wp1.7-traccc In this setup we want to process in parallel several directed acyclic graphs of dependencies between data-transformations, where some of the data-transformations may invoke asynchronous GPU operations such as memory copies or launching kernels. The fibers/coroutines are used to suspend the data-transformations until relevant async operations are finished so other data-transformation can be executed in meantime without blocking CPU. The coroutines/fibers are used only in orchestrating, no coroutines/fibers are supported in the kernels. The experience with Capy was very satisfactory. In particular the protocol is easy to reason about. In benchmarks, performance was essentially the same as stdexec and TBB-based suspension suggesting that coroutine overhead is negligible for this application. From a developer experience perspective, I consider Capy to have significant advantages over stdexec: compilation times were shorter, error messages were clearer, the documentation was available and useful, and the abstraction contract for implementing custom components was substantially simpler, enabling more concise implementations. As an example, several strategies for handling completion of CUDA operations were explored, including polling, callbacks, and execution on a dedicated thread. This required implementing custom awaitables. One such awaitable checks whether an operation has completed; if so, it resumes execution, otherwise it schedules another check on the current executor. Implementing this with Capy was straightforward and expressive. In contrast, achieving the same behavior with stdexec was much less clear. For now it was implemented using `repeat_until`, which is a stdexec-specific extension and IIRC was not standardized as part of C++26. One of the conclusions from the project was that for this use-case any sane form task type standardized be it senders, pure-coroutines, would be acceptable as long as as it would provide a common interface for exposing asynchronous operations across library boundaries. Having said that, from my perspective, senders address two concerns simultaneously: asynchronous execution and heterogeneous programming (single-source code that can be compiled for both CPUs and GPUs from different vendors). The long-term adoption of the heterogeneous part remains to be seen. For asynchronous programming alone, however, I found coroutine and in particular Capy's model to be significantly more natural and expressive. 6. Are the libraries ready for inclusion in Boost? I would be happy to see this library as part of Boost and don't see any critical flaws that need to be addressed. 7. If not, what changes would you recommend before acceptance? - 8. Do the libraries fit well within the existing Boost ecosystem? The library appears to partially overlap with the design space of existing Boost libraries such as Asio and Cobalt. At the same time, it is noticeably different, as it proposes a new model built around coroutines from the ground up, whereas coroutine support in those libraries is layered on top of a different underlying execution model. For example, while evaluating coroutine libraries for the R&D project, I initially investigated Asio and Cobalt but concluded that they were not a good fit for project requirements (parallel execution, non-I/O, ...) and decided not to explore them further. In contrast, I see Capy as addressing a wider space and potentially providing a stronger foundation for coroutine-based development. I can also imagine that including Capy in Boost could foster a new ecosystem around its programming model, encouraging the development of Capy-compatible interfaces for existing Boost libraries. 9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed? I did not encounter any critical issues while evaluating the library. My only suggestion is that presenting Capy primarily as an I/O library may understate its broader applicability, as I found it useful in contexts beyond I/O. In my view, the library consists of a generic asynchronous execution model, with I/O facilities built on top of it rather than defining its scope. In particular, the name `IoAwaitable` suggests a close association with I/O, whereas the protocol actually describes a convention for sharing an execution context that is independent of I/O and can be applied to arbitrary asynchronous operations. A name that reflects this more general role might better communicate the abstraction that Capy provides. --- Verdict I vote ACCEPT.

2 1

Capy & Corosio Review
by iantorres＠outlook.com 06 Jul '26

06 Jul '26

Hi, It's my first review. I'm a junior c++ developer, honestly. so i can't argue about deep stuffs of those libraries. I'll provide you my experience walking through the docs. Which maybe is the better that i can do. Consider a newbie getting your docs. Probably in 2026 he uses AI for everything. Don't know if the search tool is disabled on that environment or not but can't find key concepts that i want to know. Like "How to debug", "How to build", even if that's on "Quick Start". Ignore this if is just a environment related issue. MPC and AI based docs. Even if you're a purist, big beard dude, AI agents can be get started in a easy way if you've docs, specially made for it. Human oriented docs are good made. No comments about it. Content is easy to understand even by myself. You can imaginate so many stuffs that can be created in order to make your library usable in the second 0. Just to don't leave the imagination get forgetted: 1. Boost docs trained model to build boost based applications. (this is great) 2. Boost receptionist chat agent so he ask you ¿What are you building? | ¿What's your use case? -> Use A, B, C library. 3. Boost starter kit builder (Like https://v0.app/) Sorry if that's out of topic ... Congrats for the results. I'm waiting for both libraries so i could build my apps using it.

2 1