Re: [boost] [metaparse] Practical usefulness

Subject: Re: [boost] [metaparse] Practical usefulness
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2015-06-02 22:07:31

On Jun 2, 2015 5:07 PM, "Niall Douglas" <s_sourceforge_at_[hidden]> wrote:
> In other words, I think we're moving from an era of "many need this
> so we'll build it" into an era of "I think this is cool, so I'll
> build it and if one or two other people come to use it then great".
>
> If I am right on that, it has profound consequences on what Boost is
> and how it works going into the future, especially as there is little
> incentive to buy into individual ivory towers from a user's
> perspective if that tower is locked into its maintainer.

I think you are misunderstanding these libraries a bit. These aren't really
niche in the sense that they are highly domain specific or odd curiosities
that are simply "cool." Both this and VMD (and mpl and preprocessor and
fusion and proto, etc.) are general tools whose primary consumers are other
library developers. I understand that you don't immediately see the "I need
this library to accomplish X end goal," but that's because these libraries
aren't of most use directly to the end user. If you are developing
libraries, and especially if you are developing EDSLs, that's where these
libraries shine and why they are so important. Saying that they are niche
undersells them a bit. MPL and preprocessor, for example, are/were an
important dependency of many other important boost libraries, despite most
top-level users not necessarily even being aware (except in the crazy
compile-time errors, heh).

My point is, things actually haven't changed in boost, here. We have always
embraced libraries that make it easier to develop other libraries. In my
personal opinion, these are the most valuable kinds of facilities that
boost provides, since their existence can make even higher-level libraries
actually tractable when they may not have appeared so before. If you are
stuck on not seeing a direct usage of a library for your average
programmer, try to take a step back and think about what libraries you can
build on top of the library now that such a facility is available. There
have been a handful of examples already that are very compelling and it's
not too difficult to come up with more -- the design of effectively any
EDSL in C++ can be impacted by a library such as this.