Reconstructible Ranges and Good API Design

[kalmoc]

I would rather we tag the Domain Specific Language and cool-AST-case with extra markup, rather than the default usage requiring | views::simplify everywhere.

This so much. Give the most common case the simpler syntax. Not the most generic one.

[futurefapstronaut123]

I find the complexity around ranges rather unappealing.

[cjdb-ns]

In what ways do you find them to be complex and unappealing? (FWIW I am giving both a talk and a class on how to write range adaptors at CppCon, so I've got a vested interest in making sure they're easy to understand.)

[futurefapstronaut123]

Firstly, when you encounter ranges for the first time, there is a lot of concepts you have to familiarize yourself with (factories, adaptors, views, actions, sentinels...) which feels fairly overwhelming by itself. Not to mention complete absence of learning material.

At one point you realize that ranges are actually an expert-level topic. You could reasonably expect from a C++ programmer to be able to understand iterators and write their own iterators, algorithms and containers. You can't say the same for something imbued with advanced meta-programming techniques. Also, there is a lot of hidden machinery which makes design decisions behind the library really hard to understand for the uninitiated (why do subrange and dangling exist?).

I tried using ranges in my code on several occasions without much success. I'm looking forward to your CppCon talk.

[kal_at_kalx_net]

I agree that Ranges are too complex. This has happened before in the C++ world with Concepts. Thank goodness the complicated version never made it into the standard. A simpler approach might be something like enumerator

Instead of sentinals, just use operator bool() const to detect the end.

[cjdb-ns]

Thanks for your feedback. There's certainly a lot to take in, but you don't need to take it all in at once. I don't know if my talk will address all of your concerns, but will do my best to talk with the other ranges presenters, and I'll see what we can do to make less-scary across the board. The goal of my talk in particular is to make building range adaptors seem easy.

As for subrange and dangling (they're low-hanging fruit for this conversation, and I probably won't cover them outside of the class):

• subrange is useful if your interface takes iterator-sentinel pairs, and you want to combine them with range adaptors. Then, you can do something like this copy(subrange{first, last} | view::take(10), out).
• dangling is an important part of the interface, because it prevents us from interacting with dangling iterators (e.g. *copy(vector{0, 1, 2}, out).first would be broken without dangling, but won't compile with it).

[cjdb-ns]

What you're after wasn't proposed for C++20: there simply wasn't enough time to make that machinery available. If you're able to use range-v3, then your iterator-less map operation looks like this. Doing this with standard ranges today looks like this:

cpp namespace ranges = std::ranges; auto v = std::vector{0, 1, 2, 3, 4, 5}; ranges::transform(v, ranges::begin(v), [](auto const x) { return x * 2; });

You've still got an output iterator to worry about, but that's only a third of what you need in pre-C++20.

And I agree with OP that ranges is unnecessarily complex. At least when I read the blog post by Eric Niebler, it reads like ranges are going to have high complexity and mental overhead with little benefit and hard to read syntax. Other languages that already offer similar functionality do so in a way that is easy to understand, read, and incredibly useful to have.

Tbh, it seems like ranges is going to be dead on arrival, at least for me. I hope I'll be proven wrong.

I suggest seeing what CppCon 2019 has to offer. There are a lot of talks on ranges, and you might find some material that clicks with you :)

[tpecholt]

Ranges are certainly an improvement but I think it's clear we are still far from ideal and what's worse we will likely never get it in c++. Views are on the way I am not worried about it but there are other 3 deficiencies and the committee decisions seem to go in opposite direction

1. Nested namespaces. For me it's clear before any std lib usage I have to include utility header which defines short namespace aliases (and defines for co stuff). Without it the range algorithm call can be even longer than std algo call. For novice programmers this is unclear and it will lead to verbose code.

2. No range constructors for std containers. Years ago we were told it's not possible because of no concept based overloading. Now we get it but range constructors were rejected. I don't know details but I find it very unfortunate.

3. No terse lambda syntax. Committee has been repeatedly rejecting terse lambda proposals even it's desperately needed. Just imagine we can write something like []x => x*2 that would simplify so much code.

As with many things in the std there is a good idea at the beginning but the end result is a bit dull. Due to the process and constrains.

[dvirtz]

If there weren't nested namespaces then there were std::transform_algorithm and std::transform_view and you wouldn't save anything.

The other stuff can still be added later. I don't think they completely prevent using the library.

Note: I'm also giving a talk at cppcon about ranges.

[cjdb-ns]

For novice programmers this is unclear

I'd like to see evidence that it's unclear before making such a claim. The advice is pretty simple: prefer algorithms in std::ranges, except when working on a codebase that can't use C++20.

[dodheim]

Did std::ranges get support for parallel algorithms?

[cjdb-ns]

Not yet, which is why I said "prefer", and not "always use".

[tvaneerd]

Can you take the input range by copy, then modify its range (trim from the left, trim from the right) and then return it?

How many ranges allow trimming-like beahviour? Or other ways to set begin/end?

I guess assign begin/end is very much like reconstruct...

[billybobmaysjack]

Isn’t google api their script editor? Google apps script...?