[boost] Re: enable_if review

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-10 14:24:43

"Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
news:bm63j5$b0g$1_at_sea.gmane.org...
First of all, my vote is to accept enable_if.

> [...]
> While this is necessary for the MPL itself, it puts a price on
> other components.

Or maybe it adds value to other components, since working
with MPL gives you more out-of-the-box stuff to do with them.

> I don't want to judge this, it's just an observation so far and
> I'd like to raise my concerns about it. The MPL is IMHO a
> framework, not a library.

I'd say it's both, like the STL.

> It depends on conventions others have to fulfill. The
> implementation and documentation of enable_if is much
> larger than what it would probably be without the MPL.

But is that really a bad thing?  std::sort() is much more
complicated than it would be without the STL.  Abstraction
has its price, but we pay it because of the reward.

> Also, the MPL seems to contain things that would - to me -
> make sense in other parts of boost. Shouldn't template-
> traits be part of the type-traits library? When I posted some
> ideas to add template-traits to the type-traits library, I was
> told that the MPL already contains these parts. Point 3 from
> above now even suggests to move enable_if to MPL.

Well, there is a danger in letting MPL become the Borg.
On the one hand, we should seek to refactor stuff that doesn't
need to be in MPL into independent libraries that can be
used on their own.  Which means that if traits could all be
moved to the type traits library, I don't see why they shouldn't.

On the other hand, MPL provides a lot of infrastructure to
support the features it provides, so I suspect that when
something is in MPL, it is because it already depends on
that infrastructure (both compiler hacks and building blocks),
and so someone using the feature already needs MPL
anyway, even if the feature is put in another library.

The problem is that MPL is kinda like an RTL for the compile-
time world.  It provides a lot of fundamental services that
other meta-stuff can use, which is also part of its purpose.
So maybe people who want to do a lot of meta-stuff will just
have to get used to it in the way we are used to linking to an
RTL every time we build a program.

> [...]
> In my code, I would like to use
>
> enable_if< myBool, myType >::type
>
> without the _c. It's easier to write, read and teach to
> colleagues. I can live with the _c, but I don't like it. It's one of
> the visible costs the MPL framework places on otherwise
> unrelated components.

But here it isn't a cost.  MPL provides more functionality,
and to support that, you necessarily need to have two
different names.  I would call it a "visible benefit".

> Do others share my concerns?

I can see where you're coming from, and I agree that it can
be startling that such a big thing as MPL is hiding in the
background of so many smaller utilities.  On the other
hand, I think MPL's utility is only gaining momentum, so
you'll probably have to come up with a stronger complaint
than a trailing "_c" to argue why it shouldn't be considered.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003