Rappel: Compose Algorithms, Not Iterators - Google's Alternative to Ranges - C++Now 2024

---

Rappel: Compose Algorithms, Not Iterators - Google's Alternative to Ranges - John Bandela and Chris Philip - C++Now 2024
---

Is std::ranges the best way to compose operations on ranges?

What if instead of basing composition on a generalization of ＜iterator＞, we instead based composition on a generalization of ＜algorithm＞?

What if doing this enabled us to make composition safer, more efficient, and more flexible compared to C++20 ranges?

And what if we got monadic error handling as a bonus?

Join us for an introduction to Rappel - a library implementing this approach!

We will begin by examining the motivation for Rappel, including an in-depth analysis of its underlying semantic model, which differs from std::ranges.

We will explore the tradeoffs between this model and std::ranges.

Finally, we will delve into the implementation of Rappel and discuss how it can be extended.
---

---

John Bandela

Loves working with C++ T-Rexes at Google
---

Chris Philip
---

C++Now 2025 - 28th April - 2nd May
C++Now is an annual onsite international C++ programming and coding conference held in Aspen, Colarado. For all C++ developers, C++ software engineers and those involved with the C++ language, CppNow provides an indepth and technical content provided by the best and brightest C++ experts of the C++ world.
Video Sponsors: millennium and think-cell
---

---

#boost #google #algorithm #cppprogramming #cpp

[PerriPaprikash]

Would have been way better if Rappel used standard C++ snake case, as it would make the code more readable within other code.

[zartajmajeed]

46:09 - This is not open source - would've liked it to be the first slide

[petyabubkin]

I hope this becomes an open source project.

[thai-cheese]

This feels very similar to the concept of transducers in Clojure, which is a subtle concept that has to be added into the language after the fact. I've found writing a Clojure transducer can be very tricky unless I have a clear understanding of the shape of the data in every step through the flow, which becomes a run time error in Clojure and likely a very complex template error in this library.

[AlfredoCorrea]

This shows that ranges are not the solution to all problems. Some problems need a different model; it is more than just being less error-prone (danglings). It also reminds me of Jonathan Boccara's "Pipes" library, which sounds very similar, if not the same deep down.

[zartajmajeed]

Pretty damning indictments of C++ ranges - 11:06, 23:10

I wonder how devastating this is for the compilation.

[ciCCapROSTi]

Gonna be curious how is this better than a good list of map reduce calls, or the recent piping in C++.

[cassandrasinclair]

"Pipeline style" programming is very common in functional languages; it really is just composition of transformations and working with invariants.

[andrewcprock]

11:37 According to the formula, stack size growth is quadratic, not cubic.

[TheSulross]

If there is not a firm intention (already) to make this public, open source, why even bother to talk about it at conferences? To get wider, public feedback, then need to open source it.

Also, concur with snake case comment - Google should embrace the convention practice of the pervasive, wider C++ community (and with the std lib as official example of said convention practice) - if has any intentions of promoting some C++ code to be public, open source.

[paulluckner]

He flies over slides with code. Don’t like that too much..

[lengningliu]

Isn’t incremental = map and complete = reduce? It would be better if C++ attempts to mimic functional programming adopt functional programming terminologies correctly. This reminds me the Expected monad that has left and right type messed up. Don’t do that.

[harrybims]

1) The cubic growth equation that is supposed to model the growth in the stack size doesn't match the stack size numbers on the previous slide. 2) The assertion that the std::ranges example would result in the allocation o 1M^3 bytes of memory is also incorrect. 3) The example of using std::ranges in a way that crashes the system is not the fault of std::ranges. It is the fault of the programmer who defines lambda functions whose parameters is an lvalue, when everybody knows the pipeline sends rvalues to the next stage; 4) the problem with views::filter dereferencing twice is not the fault of the std::ranges, it is a bug in the implementation of views::filter. The fix is to assign the dereferencing of the iterator to a temporary that is used in both places in the filter.
The above is cause for concern about the comparison test results.

[sirhenrystalwart]

Functional programming is unreadable. Just give me for loops.