[boost] Re: enable_if review

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-11 09:23:50

Daniel Frey <daniel.frey_at_[hidden]> writes:

> Maybe I'm nitpicking now, but from MPLs POV, the naming convention
> is to use _c for the "special" case that you want to provide the
> value directly. But I wonder if this was a good choice as it seems
> to me that from an outside perspective, it would make more sense to
> add a _t the MPL-version of the general part. This would IMHO be
> more consistent and remove the small price for people that use
> enable_if without caring about the MPL. But that is actually the
> smallest issue, I think the separation of components (with separate
> documentation!) is much more important. Having template-traits is
> nice, but when they are hidden inside MPL and not documented, they
> are close to useless for me. 

But Aleksey didn't consider it part of MPL's charter to provide that
in a way that you could use it.  Likewise, I have indirect_traits.hpp
in boost/python/detail, with things like is_reference_to_constant.  If
someone else is willing to go to the effort to factor it out, document
it and take it through (mini) review, then everyone else can use it.
Otherwise, and until then, it remains hidden.

> Look at the history of enable_if: It was developed several times
> independently IIUC and just now we are giving it the attention it
> deserves as a valuable technique on it's own. 

Not quite; it was developed once by Jaakko et al (**); they wrote a
paper on it, and people implemented their technique several times in
Boost.

(**) actually someone else developed the technique independently - I
forget who - but he didn't carry it to enabling template
specializations and he didn't call it enable_if.

> I'm in no way against the MPL, I just would like to make people
> think about factoring out components. My experience is, that it's
> these little helpers that are often more needed than large libraries
> and frameworks in my job. It's also easier to convince your boss
> that you need a small tool like enable_if instead of the whole MPL,
> YMMV.

Oh, and BTW, I'm not advocating sticking enable_if into MPL.

At the same time, if a library author needs a component to get his job
done, and writes it, he shouldn't feel compelled to put that component
through a separate review if it's not part of his mission.  Template
traits or whatever you're calling them falls into that category.

>> 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.
>
> Exactly. As Dave also mentioned: type-traits and tuples are also
> good examples for things that would well be seen as MPL components,
> but that are currently (and luckily) independent from the outside
> perspective. 
> Whether or not they use some parts of the MPL (which uses the
> Preprocessor Library, which uses...) is another story.

Yes, they do have a few dependencies on parts of the MPL, and in fact
they could be written more simply and in some cases much more
efficiently in compilation resources if they were to use the MPL.  I'm
fairly sure that Jaakko and Joel's new tuple implementation (in the
sandbox) makes liberal use of MPL and would've been much more
difficult without it.  So while I agree that they may belong outside
the mpl namespace, I also agree that *physical* independence is not
neccessarily desirable.

>> 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.
>
> As I said, I don't mind the dependency. I just think that we should
> have separate and independent documentation of some parts...

If you're after template arity detection or some other MPL internal
component, all I can say is, "feel free to apply elbow grease".

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com