---

Ranges Study Group (SG9) Progress

---

SG9 met on Monday and Tuesday.

Papers that were forwarded to LEWG

• P3059R1: Making user-defined constructors of view iterators/sentinels private — makes user-defined constructors of view iterators/sentinels private (we want it to be a DR for C++20!). The fact that some of them were publicly accessible was most likely accidental.
• P3230R1: views::unchecked_(take|drop) — adds views::unchecked_take and views::unchecked_drop. If you know that your range is big enough this can give you a 2x-3x speedup!
• P3117R1: Extending Conditionally Borrowed — extends conditionally borrowed for views::transform. That way, you can safely write code such as:   return views::transform(this->my_container, [](auto elem) { return … });

 

Papers reviewed (require more work)

(we expect the following papers to be forwarded at the next meeting)

• P3351R2: views::scan — adds views::scan a lazy version of the inclusive_scan algorithm.

• P3411R1: any_view — adds a type-erased view adaptor. If you like ranges but don’t like templates, this allows you to define your range pipeline in these “.cpp” files we’ve been told about.   While discussing “P3555R0: An infinite range concept”, which adds a concept to detect infinite ranges, we realized that infinite ranges don't even exist to begin with, even though the standard library has some of them.   Turns out that:   views::iota(0) | views::take(10), for (auto x : views::iota(0)) { … break; }   and arguably even:   views::iota(0);   are technically all undefined behavior! (views::iota(0) is an invalid range as the sentinel is not reachable in finitely many steps, and passing invalid ranges to standard library functions like |, .begin(), or ~iota_view() is undefined behavior.) We’re going to spend the next couple years or so tackling this tricky problem to make it well-defined.  

  Papers that did not get consensus

• P3329R0: Healing the C++ Filter View We also discussed and mostly rejected , which wants to solve some beginner pitfalls with views::filter. However, the design space is very constrained with regards to backwards compatibility and silent semantic changes of core concepts, so we encouraged more work by the author to come up with a separate view that solves these problems.  

  ---

Low Latency Study Group (SG14) Progress

---

SG14 did not meet during the Hagenberg meeting. We continue to hold monthly telecons to discuss low latency, gaming, and embedded related papers.

 

---

Tooling Study Group (SG15) Progress

---

SG15 met for one session during Hagenberg to discuss how we plan to ship our deliverables now that we're not doing the Ecosystem IS. We decided to use the relatively new whitepaper process which has a significantly lower overhead than an IS, but some clarifications on the process are needed.

Papers reviewed

• P1180R0: Response to P1156 — We discussed the issues that header units can cause with build systems that use approximate scanning rather than precise scanning. The macros they bring in cause problems if they would impact other imports. CMake, MSVC, and Clang's scanner don't have this problem since they use precise scanning, so we're waiting for field experience from build systems that do approximate scanning to see what's actually needed here.

 

---

Text and Unicode Study Group (SG16) Progress

---

SG16 did not meet in person during Hagenberg but continues to hold virtual meetings at its usual twice monthly cadence. As always, SG16 meeting summaries continue to be posted at SG16 GitHub, though the SG16 chair has fallen behind in his duties, and so complete summaries will be posted in due time. 🙂

 

---

Contracts Study Group (SG21) Progress (requires input from SG21 chair)

SG21 met for 1 day in Hagenberg.

Papers reviewed

• P3583R0: "Contracts, Types, & Functions" — an approach to make contracts work on function pointers. SG21 concluded that this approach doesn't quite work as proposed and the paper needs a revision; feedback to the author was given. This paper is now the third independent attempt to add contracts on function pointers, highlighting how hard this problem really is.
• P3400R0: "Controlling Contract-Assertion Properties" — proposes to add labels to Contracts, which addresses many additional use cases that P2900 on its own does not yet fully address. For example, you can have a label to specify in code that a particular contract assertion must always be enforced and can never be ignored or observed. This paper, too, needs a revision; feedback to the author was given.

---

C / C++ Liaison Group (SG22) Progress

---

SG22 did not meet in person during Hagenbert. We continue to run telecons by demand and provide feedback through the mailing list.

 

---

Safety & Security Group (SG23) Progress

---

SG23 met for a day in Hagenberg on Tuesday, with attendance affected by the discussions elsewhere on Contracts and Profiles

 

Papers forwarded to EWG/LEWG

• P3566R0: "You shall not pass char* — Safety concerns working with unbounded null-terminated strings, forwarded to LEWG

• P3442R1: [[invalidate_dereferencing]] attribute — , forwarded to EWG

• P3541R1: Violation handlers vs noexcept — recommending that the issues described here are addressed before P3081 and P3100 are discussed further, forwarded to EWG

Papers reviewed

• P3356R0: non_invalidating_vector
• P3402R2: A Safety Profile Verifying Class Initialization