Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-10-24 18:26:53

> 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.

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

Secondly the Standard C++ Foundation sponsored Eric to design and write
Ranges v3 for the purpose of immediate standardisation. 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).

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.

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. Secondly, optimisers currently are not well tuned for
Ranges, and too easily give up which causes poor codegen. Thirdly, there
are definitely problems at the intersection between other stuff and
Ranges e.g. Eric wants lots more async and coroutines, and while I am
not competent to speak on other intersections, in the area of file i/o I
am very sure he is wrong on that, and indeed I dropped async file i/o
entirely in P1031R1 after he couldn't give me a compelling use case to
retain it. I will be starting work soon on the paper standardising
support for next gen storage e.g. Samsung KV-SSD, and Ranges does not
fit at all well with that either. Ranges may, or may not, have to be
adjusted to cope. I have yet to discuss this with Eric, it'll be next
year at earliest.

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.

Niall