44:00 the change from call-operator to std::invoke is especially cool for projections, as it allows calling member functions or accessing data members simply by passing pointer-to-member as the projection. Great talk

Have yet to switch to C++20 (gcc format support, pls! and other stuff), this talk was just right for me, easy to follow and learned a lot! Thanks

A view is a range such that: * its move operations are constant-time * (if it is copyable) its copy operations are constant time * destruction of a moved-from object is constant-time * otherwise, destruction is O(N)

One of the best talk on ranges! Thank you. I know it's still very new, and I would love to see some discussion about performance numbers, as well as compile times. What to be careful about.

For the last problem (string trimming), I'd say an even cleaner way to do the trim function would be: auto trim() { return views::drop_while(::isspace) | views::reverse | views::drop_while(::isspace) | views::reverse; } handles both front and back trimming. Nice and elegant

the dangling example at 11:00 ish, if ranges didn't do that ASAN would pick it up as a use after free.

Shouldn't template std::string to_string(R& rng), need to constrain to R being a range of a char convertible type too?

Makes me wonder if these first-class functors with composition are going to stay limited to range adaptors. It feels like Alice in Wonderland to have to write a singleton range, like {&x, &x+1}, just to use these abstractions on the base types of the language. I know it’s just a demo, but is a string-manupulation function that only works on 8-bit character sets really going to cut it in this century? Maybe there’s a need for a library that stores strings in some sensible form (UTF-8 NFD, stored in a dynamic array of char8_t), ensures that any data stored in it is in properly encoded, and then provides adapters to convert it to other formats. In this case, if there were a member that provided a view of the codepoints as a sequence of wchar_t objects, you could pass that to iswspace() and re-use most of the same logic. (Except on Windows, where wchar_t violates the Standard by not being a fixed-width encoding, so the standard library might break on UTF-16 surrogate pairs.) This lazy conversion through iteration over a range could be much more efficient than eagerly converting the UTF-8 string to a wide string, processing that, and converting back. (In a library that needs to remain thread-safe even if some other thread concurrently changes the global locale to one with a different definition of whitespace, you would also need a locale parameter, which could default to the one that was global at the time of the call But that isn’t related to your main topic.)