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)

[wg21bot]

P1028R3 SG14 status_code and standard error object (Niall Douglas)

[brycelelbach]

Prague 2020-02 LEWG Minutes

P1028R3 std::status_code and std::result<T>

Chair: Bryce Adelstein Lelbach

Champion: Niall Douglas

Minute Taker: Thomas Köppe

Start Review: 2020-02-13 13:59

Examples: Yes, in paper.

Implementation experience: Yes, in paper.

Usage experience: Yes, in paper.

Wording: No.

At Cologne 2019, LEWG voted to discuss this paper on the reflector, then bring it to Belfast and prioritize it for C++23.

• Did the reflector discussion happen? What was the outcome of that discussion?
• It appears that this paper was not seen at Belfast; is that correct?

Things in this paper:

• status_code
• result<T> (builds on top of status_code)
• erased<T>
• string_ref
• Interactions with language evolution:
  • P0709 deterministic exceptions
  • P1029 relocating objects
• ABI resiliency mechanism.

We need to scope this discussion.

Suggested scope for today:

• Don't discuss the P0709 and P1029 language interactions.
• Don't discuss string_ref: treat it as "TBD" and bring a separate paper for it.
• Don't discuss erased<T>: treat it as "TBD" and bring a separate paper for it.
• Focus on the core design of status_code and ABI resiliency mechanisms.

Start with examples on Page 3/Page 4?

Big questions:

• How does result<T> differ from expected<T, E>?
• Semantic instead of exact matching for comparison.
• Is erased<T> essential to this proposal? Should we move forward without erased<T> in this paper?

Comparison with error_code: Slide 4.

Add table comparing error_code and status_code.

Alternatives to status_code_domain being distinguishable (for comparisons) by a user-provided unique integer:

• Compiler magic that builds a registry.
  • Can this be done entirely at compile time.
• SHA hash.

POLL: We are okay with status_code_domain being distinguishable (for comparisons) by a user-provided unique integer.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
1	6	9	1	1

Attendance: 32

# of Authors: 1

Author Position: F

That has weak consensus.

Please explore the alternatives in a future revision.

status_code_domain destructor:

• Does requiring that status_code_domain be constexpr constructible really imply that it has a trivial destructor?
• Should status_code_domain have a virtual destructor?
• Make status_code_domain's destructor virtual and constexpr.
• Refer to ARG?

If this is all made consteval, can we evolve the vtable in the future?

POLL: We must be able to add new dynamically dispatched methods to status_code_domain after we ship it.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
0	0	3	10	4

Attendance: 29

# of Authors: 1

Author Position: SA

That has unanimous consensus against.

Open questions:

• Do we require that status_code and result<T> are freestanding-in-practice?
• Do we want win32_code, ntkernel_code, and com_code in the first version of status_code we ship?
• Do we want posix_code and getaddrinfo_code in the first version of status_code we ship?

End: 15:45

__CONSENSUS: Bring a revision of P1028R3 (std::status_code), with the guidance below, to LEWG for further review.__

• Remove uses of facilities from P1029 until it is in the IS.
• Split string_ref into a separate paper, or at least remove it from this one.
• ABI resiliency is not a requirement for the proposal to proceed.
• Ask ARG for input on ABI resiliency in P1029.

[brycelelbach]

P2170R0 (Feedback on implementing the proposed std::error type, #879) should be seen the next time this paper is seen.

[ned14]

May I suggest that SG14 ought to process P2170 and suggest what it feels appropriate ought to be merged into P1028? P1028's design came from SG14 originally, that was a design ticking all the concerns from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0824r1.html.

For my ha'pennies worth, there are parts of P2170 which SG14 actively discussed and proactively rejected; there are other parts of P2170 where people were on the fence; and there are still other parts of P2170 where hitherto, the value add of providing those facilities wasn't felt to be sufficient, but perhaps in the light of P2170, and more empirical experience since gained, that perhaps some of the P2170 extensions ought to be merged.

BTW I don't expect another revision of P1028 until F2F meetings resume next year. Lack of bandwidth due to stuck at home unable to travel more than 5km. However between now and then a round at SG14 with P0824's authors is certainly doable.

[wg21bot]

P1028R4 SG14 status_code and standard error object (Niall Douglas)

[ned14]

Errata on P1028R4 so I don't forget for R5:

• string_ref should have been replaced with "implementation defined type" as per LEWG request.
• status_code_ptr should have been renamed to nested_status_code as per LEWG suggestion.
• Making a nested status code ought to be able to take an allocator.

Not sure how I missed those when I made R4, I'm going to blame the usual causes of tiredness and/or lack of coffee.

[ned14]

Chapter 4.17 code example does not compile.

std::erased<T> stomps over an important name in std

[ben-craig]

2023-02-07 13:00 to 15:15 Issaquah Library Evolution Meeting

P1028R4: std::status_code and std::result

2023-02-07 13:00 to 15:15 UTC-8 Issaquah Library Evolution Minutes

Champion: Niall Douglas

Chair: Ben Craig

Minute Taker: Steve Downey

Start: 2023-02-07 13:00 UTC-8

Does this paper have:

• Examples? Yes
• Field experience? Yes
  • Implementation experience? Yes
  • Usage experience? Yes
  • Deployment experience? Yes
• Performance considerations? Yes
• Discussion of prior art? Yes
• Changes Library Evolution previously requested? In progress
• Wording? No
• Breaking changes? No
• Feature test macro? No
• Freestanding? TBD
• Format and/or iostream support? No

End: 14:05

Summary

POLL: We are happy with the current high level design, and encourage Niall to provide wording for further LEWG review.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
18	8	0	1	0

Attendance: 21 local, 13 remote

# of Authors: 1

Author Position: SF

Outcome: Strong consensus

WA: Design is pretty good, not sure I'm sold on the feature

Action Items: desire for alternative to std::erased name

Next Steps

Provide wording so that LEWG can do a wording review.

[brycelelbach]

When this is next discussed, P2170 (#879) should also be reviewed.

[ned14]

I thought we discussed P2170 at Issaquah and the room felt my summary of it in R4 was reasonable? SG14 discussed everything in P2170 long ago, where it deviates the design in P1028 doesn't do what P2170 wants for good reasons, all of which I listed both in R4 and in the room at Issaquah.

P1028R5 does make the unique id type for code domains implementer chosen, as enough people kept raising it it was easier to just turn that on rather than keep explaining the statistics about how big 64 bit spaces really are repeatedly.

[brycelelbach]

I don't recall inviting the author of P2170 to present; I'd like to allow them to have their day in court, even if we've already discussed the paper.

[ned14]

Oh they're turning up to present? Cool. More the merrier.

[wg21bot]

P1028R5 SG14 status_code and standard error object (Niall Douglas)

[inbal2l]

Library Evolution Meeting Kona 2023-11-09

P2845R4: SG14 Status_code and standard error object

2023-11-09 Library Evolution Kona 2023 Meeting Minutes

Chair: Billy Baker / Nevin Liber Champion: Niall Douglas Minute Taker: Ben Craig

Summary

The authors got directions to explore. The paper requires more discussion time, no polls were taken.

Next Steps

The paper requires more discussion time and will be scheduled for LEWG telecon/Japan meeting (depending on the availability of the authors).

[wg21bot]

P1028R6 SG14 status_code and standard error object (Niall Douglas)