Andrey Semashev wrote:
I'll shot a few questions right away. How does it affect compilation times and source code size? How widely is it supported among legacy compilers? Does it introduce any side dependencies?
According to the documentation, there is no runtime overhead. As for portability, I don't know, but a quick look suggests it supports all compilers. Still, if concept checking was disabled by default, portability or dependency on that library wouldn't be an issue.
Are there any estimates on how it affects library developing time (based on the amount of code written, for example)?
Writing the concepts correctly may be the most difficult (re-using pre-made ones helps); integrating them with code is just a matter of putting a big (arguably ugly) macro instead of the return type.
I'm asking because your proposal sounds like an overhaul of Boost libraries and a possible obstacle for getting new libraries into Boost. I, as an upcoming Boost.Log library author, am concerned whether I have to spend extra time and effort to embed Boost.ConceptCheck into my library to get it accepted.
Even if it eventually gets adopted as a guideline, I'm fairly sure you could still get libraries accepted into Boost if you provide a rationale as to why your library doesn't support it.