Re: [Capy review] Some questions
Peter Dimov via Boost <[email protected]> Wed, 24 Jun 2026 11:08:14 +0300
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <[email protected]> |
Steve Gerbino wrote: > On Tuesday, June 23rd, 2026 at 8:08 PM, Ruben Perez via Boost > <[email protected]> wrote: > > > > > > > 4) Does capy::cond::canceled add anything vs. just using > > > > > > std::errc::operation_canceled? > > > > > > > > > > No, it doesn't. It is there for consistency with our error types > > > > > that > > > don't have std spellings. > > > > > > > > Would it make sense to just use the errc one and remove capy's? > > > > Maybe Peter can suggest something here? > > > > > > We have a convention throughout the project to always compare > > > against error conditions. Making a change like that would make it the > oddball. > > > > > > Why? std::errc is an error condition enum, not an error code enum. > > To clarify, I mean our error conditions as indicated here: > https://develop.capy.cpp.al/capy/reference/boost/capy/cond.html > > "These are the conditions callers should compare against when handling errors > from capy operations." Even if you keep capy::cond::canceled, you should still make sure that comparing against std::errc::operation_canceled works (compares equal whenever comparing to cond::cancelled returns true.) And this also applies to any other conditions that have standard equivalents. _______________________________________________ Boost mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/[email protected]/message/TZ6W3JAXA47ENKJXH7RBENSKMZHXJ5P3/