From a distribution point of view, I see some big problems too. I guess the idea, if I understand correctly, is to distribute your binding generator along with the select-few boost header-only libraries, and then, the user would have to run the binding generator for his particular platform to generate the implementation-detail binding headers of those boost library
Personally, I find this proposal very scary. I'm just gonna give my opinion
on this, make what you want of it.
One little thing, I'm not sure that STL11 is a particularly good name for
this, since most of the new C++11 libraries would not be classified as
"STL" libraries (except for unordered containers and <array>). But that's
just a trivial issue of terminology.
You state in your readme for your generator:
".. or write some brittle bindings which manually replicate STL items .."
In my experience, what can make those kinds of manual bindings brittle are
all those subtle incompatibilities (often undocumented) between analogous
components of the alternative implementations. It's not hard to take a list
of standard components and turn that into a list of using statements /
typedefs / aliases within a new namespace, because such lists are not that
long in general (20 to 50 things per header, at most) and it's not hard to
do this well and to maintain them. I find that there's nothing particularly
brittle about that "human process". Replacing that process with a reg-expr
generated automatic process can only make it more brittle, with very few
benefits, and might require significant tinkering until it works reliably,
and I don't care how smart that generator is (using clang's AST lib or
not), I cannot see this becoming more reliable than a hand-written and
actively maintained equivalent. And after all that, it does not address the
main weak point of such bindings, which is, as I said, dealing with the
subtle incompatibilities and platform-specific quirks.
ports. Or, if you want to spare the user from having to do this, then you
must distribute a specific version of all the headers that will work for
their particular platform (OS, compiler and std-lib implementation) and the
particular versions of those platform components. Either way, this is a
distribution nightmare.
As for "forking" boost based on this, I don't understand why this is
necessary, or maybe I don't quite understand what it is meant to really
involve. Most boost libraries already contain a significant amount of
conditional code and workarounds to deal with platform-specific issues or
to use beneficial features that only some platforms support (including
C++11 features). Why would it be necessary to have a completely separate
version or distribution of those libraries that are targeted at platforms
with the (mythical) feature-complete C++11 library implementation? That is,
if you really mean to "fork" the boost libraries in that way, there is
going to be enormous costs associated to doing that, mostly in terms of
maintenance and man-power.
I think that a much better alternative strategy is to do what boost has
done with Boost.TR1. Why not create a library wrapper like Boost.TR1 but
for C++11/14? Isn't that what users want, i.e., to be able to use standard
C++11/14 library components and not have to worry about running their code
on platforms that don't support it or only partially? I mean, people who
use Boost.Thread today, instead of <thread>, use it because it works
everywhere. But if they could include something like