Is there a plan to support more of the views/things in range-v3 that weren't standardized?

[eigenwhat]

Right now I'm really eyeing up zip/zip_with as a means to kill off classical for loops when you need an index. It's one of the many things that are in range-v3 but neither here nor the standard. There's still a niche where projects cannot use range-v3 but can use this library, and initially trying to port over some useful stuff from range-v3 has proven to be a bit of a rabbit hole due to all the metaprogramming library constructs, leading me to maybe just do it from scratch.

Or maybe even a companion library if we want to keep the scope to what's in the standard?

[tcbrindle]

The plan is that NanoRange will only contains what will be in C++20, hopefully in such a way that upgrading to standard ranges when they arrive will not be much harder than just changing the namespace from nano to std.

Once standard ranges are widely available in shipping compilers/stdlibs, I have vague plans to write a library of extra views/actions, similar to what Range-V3 offers but using the standard-provided machinery. That probably won't be for a year or two though.

As to writing a companion library to NanoRange, I don't have sufficient time/motivation to do such a thing myself right now, but I'd be interested in seeing such a thing (and helping out where I could) if you want to give it a go! :-).

[roibarkan]

Hi Tristan, all,
I'm currently attending the C++now conference, and as part of the "library in a week" initiative I've taken interest in implemting a few range-views that aren't currently in the standard. There are a few such views that I considered, but my intention is to start with some ranges::views:merge variations.
Here are a few slides I drafted on the topic. The author/maintainer of Boost.Algorithm told me it might make sense to do it as an addition to that library.

1. If you or anyone is interested in participating and assisting - I'd be very happy.
2. Tristan - do you have any objection or issue if I use the code in this NanoRange repo as inspiration (or more) ?

My intention is to do this work with the BSL license. I have a lot of C++ experience, but very little experience with open source development.

Cheers,

[tcbrindle]

Hi @roibarkan,

I haven't heard of the "library in a week" initiative, but it sounds great!

A views::merge range adaptor sounds like a great idea, and could naturally lead on to adaptors for the other set_xxx operations as well (although these would probably need to be binary only rather than taking N source ranges).

You're more than welcome to use code from NanoRange in accordance with the licence if it helps! But since Ranges support is now widely available in GCC and MSVC I would strongly recommend using the "real" C++20 concepts rather than emulation via enable_if and SFINAE tricks as NanoRange and Range-V3 do. It will make your life much easier.

One other comment based on your slides: both a merge taking N ranges variadicly and a merge taking a dynamic range-of-ranges are potentially useful, but I'd recommend giving them different names. (In much the same way that views::concat and views::join do similar things -- glue together a bunch of ranges into a single range -- but have different names.) Both are likely to be quite tricky to implement! I think the approach you mention of starting with a binary merge and then extending this into a variadic merge sounds sensible. The range-of-ranges case can be handled later.

Best of luck with the project, I'll be interested to see the results!

Tristan

[roibarkan]

Thanks for you quick and thoughtful reply, @tcbrindle.
Here's a little information from cppnow.org about library-in-a-week.

Exactly as you describe/suggest, my intention is to write things on top of C++20 ranges. I still wanted to reach out early and raise the possibility of taking inspiration from NanoRange. I also wanted to engage the NanoRange comnmunity in case there are other already existing initiatives that I can join, and to give the community some chance to communicate.

As to the hard topic of naming, and to your point about implementation steps - thanks, I'm positive with both. In Rust they also went for different names for static-vs-dynamic merge, although their names are more descriptive - merge vs. multiWayMerge. I personally think there's some chance that people that know about join aren't aware of concat might be missing out, and thus I see value in some naming relationship (that's perhaps can be made consistent as more such cases arise) between such views - but I don't want to dwell on that...

Thanks again for the quick response,