Re: [boost] The future and present of Boost

-----Original Message----- From: Boost On Behalf Of Niall Douglas via Boost Sent: Wednesday, October 24, 2018 8:27 PM

...

Ranges-v3 (the c++11 version with the library implementation of concepts) is certainly a nice library that can be used by more people but e.g. compile-times were a real bummer and it still doesn't compile on msvc.

Also quite frankly: Given that it is yet another library that emulates a native language concept with insanely complex TMP machinery, I'd hate to see that library as a dependency of other header-only boost libraries whose compile-times will then remain insanely high years after real concepts have entered the standard. And I'm not sure if anyone will want to spend the time to properly maintain it once Eric moves on.

You appear to be mistaken regarding a few facts.

Such as? As far as I can tell nothing of what you are writing relates to anything I wrote. But let's get one thing out of the way first: I didn't want to criticize the ranges library and least of all Eric. You don't have to defend him or his work (I have the greatest respect for him and the ranges-v3 library) against me. All I wanted to express is that - contrary to what Robert implied - I don't think ranges-v3 should have been developed as part of boost or even submitted to it after the design was "finished" (for some definition of finished).

Firstly, there are now several Ranges implementations around, and I believe ALL of them compile, without hacks, on VS2017.9.

2017.9 isn't released yet, but regardless of whether my use of the term "doesn't compile *yet*" was correct or not, the point was that it didn't compile on msvc for a long, long time. Regarding the multiple versions, I know of three: 1) Ranges-v3 the "original" and continuously updated c++11 implementation which did not compile on MSVC until VS2019.9 (Have you actually tested that or are you basing this on Microsoft's announcement that it "will" work?) 2) A - long since outdated and no longer maintained - fork/port of ranges-v3 that works on VS2015 (AFAIK created by Casey Carter from MS) and only compiles because it does use lots and lots of MSVC specific hacks. 3) The reference implementation for the proposal that actually used language Concepts (https://github.com/CaseyCarter/cmcstl2). That is the one I called The ""actual" ranges library", because it shows what the library is meant to Look like with full language support and without all the TMP machinery necessary to emulate concepts in c++11. That one obviously doesn't compile with anything that doesn't have concept support, which includes msvc. Do you know any other?

Secondly the Standard C++ Foundation sponsored Eric to design and write Ranges v3 for the purpose of immediate standardization. That makes it unique amongst all libraries entering the standard as far as I know. It was commissioned given Eric's unquestioned reputation in that space as the putative STL v2 (since rejected).

I know. How does that contradict anything I said?

Thirdly Eric is no longer the primary maintainer of Ranges v3, nor has been for at least a year or more now. He is wholly consumed with getting the thing through the committees which is extremely detailed, all-consuming work. I've sat in LEWG, it's like watching paint dry as Eric answers again and again the same questions raised again and again. Occasionally there is a nugget of gold in there, and it results in a fix avoiding a corner case problem, but for the most part Eric and Casey have thought through every design point and decision. It's just going through the motions to get the thing over to LWG.

Again, I know and how does that contradict anything I said? I don't think I even mentioned Eric anywhere in my mail. I was purely talking about the ranges-v3 library.

There are valid criticism of Ranges however. Firstly, even on a fully compliant compiler, they look to be much slower to compile when used in anger, and that's probably unavoidable without more powerful language abstractions.

Which is exactly what I said: ranges-v3 has to emulate a language feature (concepts) with a complex TMP solution. That is OK for an exploratory library, to get feedback on all kinds of design aspects, but in boost with it's slow deprecation cycles it would just mean that we would have been stuck with this problem for a long time. In principle it would have meant to add a library to boost that would reach it's full potential (by replacing the c++11 tmp concepts with language level concepts) only a couple of years, after it had been merge into the standard.

[.. more challenges with ranges that I'm not qualified to comment on. ..]

So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not.

Again, where did I criticize anything that isn't in line with what you said? Are you maybe mixing up my post with the original one from Robert? Mike

Niall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost