[boost] Re: enable_if review

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-10-10 06:01:56

First of all, my vote is to accept enable_if.

It's one of those "little" things that you just need, I'm glad it's 
available now. Basically everything looks fine to me.

Now why I made this a reply to Gennadiy's post:

Gennadiy Rozental wrote:
> 1. lazy_enable_if
> 
> Shouldn't be this named apply_enable_if. It very similar to the appropriate
> MPL concept and seems logical to be named the same.
> 
> 3. utility or mpl?
> 
> It seems that submitted components belongs rather to mpl library that to
> utility. What about placing it there?

Where to start? I got the impression that a shift in the views of 
several boosters occured during the last months. While boost was 
previously a collection of separate components and therefore what I call 
a library, it is becoming something different. It seems that most thing 
are seen in the context of MPL today. While this is necessary for the 
MPL itself, it puts a price on other components.

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

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.

I think we should try to separate MPLs parts that can be used on their 
own instead of moving more and more into it. While the MPL is certainly 
a cool library, I also think that there are a lot of people that simply 
don't have the time to care about it that much. Those people (and I 
count myself among them when working on a project with a tight shedule) 
prefer very small and straight-forward components AFAIT. 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.

Do others share my concerns?

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de