On Thursday, July 2nd, 2026 at 1:16 AM, Andrzej Krzemienski via Boost <boost@lists.boost.org> wrote:
Suppose that in my program I trust the senders. I know that they deliberately do not complete the final closing ceremony for performance reasons. I treat (or want to treat) stream_truncated as eof (successfully having read all bytes). Then I cannot use these pump functions, because they will refuse to commit on this "stream_truncated treated as eof" result.
In this case you're expected to handle it yourself as we cannot make that assumption. The pump will commit all bytes before checking and returning the error. You can handle it like this: auto [ec, n] = co_await pull_from(stream, sink); if(ec == cond::stream_truncated) // trusted peer, treat as eof auto [ec2] = co_await sink.commit_eof(0);
Expression "was this canceled" bears so many different meanings, covers so many unrelated situations, that I cannot see how it makes value to treat them collectively. The situation that I may need to distinguish is "I did not finish your task because you didn't want me to". But cond::canceled is not this. It also tells me that the operating system on the remote host decided to kill the connection. Why do you add this condition when the nebulous std::errc::operation_canceled already exists?
The simple answer is uniform vocabulary. The same thing applies to std::errc::timed_out. There is no standard error condition for stream_truncated or eof so we'd have to say for some errors compare against a capy::cond and others a std::errc. You are given tools to check conditions all within capy::cond and the documentation recommends it. A remote connection closing would be a connection_reset, so you can tell the difference. I checked and this is working properly on POSIX environments, though it seems that Windows requires some additional mapping and it is missing. I've added an issue to track this work: https://github.com/cppalliance/corosio/issues/304