P1028 R6 SG14 status_code and standard error object

[wg21bot]

P1028R2 SG14 status_code and standard error object for P0709 Zero-overhead deterministic exceptions (Niall Douglas)

[tituswinters]

Discuss on the reflector between meetings, bring to Belfast and prioritize for C++23.
SF F N A SA
8 13 7 0 0

[ned14]

The main guidance needed from LEWG for this paper to progress are clear answers to the following questions:

1. Should status_code_domain::string_ref be broken out into a standalone paper and library facility on account of being particularly useful? If so, what naming is proposed? Is string_ref remaining char only based acceptable i.e. no basic_string_ref<CharT>?

2. Is the proposed vtable ABI within status_code_domain acceptable given past experience of vtable ABI constraints?

3. Is LEWG committed to assuming there will be some form of "move relocation" in C++ 23, even if it is the bare minimum viable support as proposed by P1029? (Note: EWG-I will hear P1029 this Belfast meeting given Arthur's proposal has stalled, it has yet to be seen by EWG)

4. status_code<erased<T>> is a move-only erased status code, which some people feel strongly negative about. posix_code, win32_code, generic_code etc all provide non-erased trivially copyable status codes. Is there sufficient need for a trivially copyable erased status code that we would instead have status_code<tc_erased<T>> and status_code<mo_erased<T>>? Or should we say that the library is specifically designed to be extended, and extending it with trivially copyable erased status codes is too trivially easy to be worth doing? (Note: my opinion on this depends on the answer to Q3)