Support for the Concepts TS

[h-2]

Do you plan to support C++20 concepts and possibly also the Concepts TS? I guess redefining NANO_CONCEPT as concept / concept bool is not sufficient as you need to make sure the subsumption rules work, as well...

Thanks!

[tcbrindle]

Hi @h-2, thanks for your interest in NanoRange!

The very short answer to your question is that no, I don't plan to add any support for language concepts at this time.

The longer answer is that, as you correctly point out, properly supporting concepts is not just a simple matter of redefining the NANO_CONCEPT macro -- not only do you need to deal with the subsumption rules, but you probably also want to use requires rather than std::enable_if when constraining things.

Range-V3 trunk handles this using a lot of preprocessor magic, which in principle we could adopt for NanoRange too (under the Boost licence). However, I'm reluctant to do so, because:

• I don't have Eric's skills with the preprocessor, and frankly I don't understand how it all works -- so I'm not confident I'd be able to solve any problems that might be reported
• At the moment NanoRange seems to give better error messages in some cases than Range-V3 in concepts-emulation mode: see https://godbolt.org/z/KrbUNk for example, where the NanoRange error message mentions the actual problem (list does not satisfy random_access_range) but the Range-V3 version does not
• I haven't done any tests and this is purely speculation, but I'd be worried that the extra magic to support both real and emulated concepts might have a negative impact on compile times in the emulated case

The other thing to mention is that unlike Range-V3 (which has tons of views and actions which have not yet been proposed for the standard), NanoRange intentionally only provides what will be in C++20 (that's the "nano" part, for large values of "nano"!). By the time we have conforming C++20 compilers, I'm hopeful that their standard libraries will also come with implementations of std::ranges, making NanoRange basically redundant there.

I hope this answers your question, even if it's not the answer you might have been hoping for. If you have any more questions about NanoRange, please let me know :-).

[eigenwhat]

The concepts emulation and metaprogramming magic is probably a major contributor to why C++17 "conformant" MSVC prior to VS2019 can't compile C++14 library range-v3 at all, and even then the 2019 compiler can only do so with some special switches, including the still experimental C99 preprocessor. Whinging aside, it'd likely have a negative effect on this library's platform compatibility.

[tcbrindle]

even then the 2019 compiler can only do so with some special switches

In fairness, NanoRange also requires the permissive- special switch in order to work on MSVC.