On 10/22/18 11:53 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost
On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 3:33 AM But now Ranges may come as part of the standard in C++20. And then sometime after may be available when/if compiler vendors choose to implement their own version. All in all, the committed would have been able to spend time on other stuff which only they can do.
They would still have had to spend the time on standardizing ranges-v3. I don't see how ranges-v3 being in boost instead of a stand-alone repo would have made any difference for standardization, unless you assume that it would have produced a much superior design.
Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.
Also, considering that the "actual" ranges library depends on concepts, I don't see how that work could have been done as part of a boost library which is commonly expected to work with a wide variety of compilers / compiler versions.
This is not quite true, in general. IIRC, when Hana was accepted, it was working only on some bleeding edge versions of gcc or clang, which were not even shipped in any distros at the time. Of course, Boost libraries strive for portability, but at the same time they are allowed to require a certain minimum C++ version. This is a per-library balance.