Boost logo

Boost :

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-11-10 00:20:38

David Abrahams wrote:
> Eric Friedman <ebf_at_[hidden]> writes:
>>David Abrahams wrote:
>>>Eric Friedman <ebf_at_[hidden]> writes:
>>>>While some of the names are a bit longer, I feel the changes are
>>>>beneficial to the library.
>>>>I will soon update the documentation to reflect these changes.
>>>FWIW, I'm a little sorry I planted the "make_" prefix in your mind.
>>>It's usually only used for runtime functions, i.e. object generators
>>I was worried about confusion that might result from simply calling
>>the metafunctions 'recursive_variant' or 'variant_over'. Though
>>attempting to instantiate these types directly (rather than their
>>exposed ::type) would immediately lead to an error, I feel it might be
>>less than obvious to the user why the error has occurred.
>>That is why I chose the make_XXX names. My intention was to echo names
>>such as mpl::make_identity.
> At some point users need to learn to deal with the metafunction idiom
> or we're going to be adding make_ to the beginning of every
> metafunction name.

I think there is an important difference between classes that are true
metafunctions vs. those that are metafunctions only because of a lack of
template typedefs. That is, even if C++ today had template typedefs, I
believe true metafunctions would not use the feature.

[For instance, consider type traits and MPL algorithms. If these were
template typedefs, then instantiation would occur immediately. This
would prevent many good things, such as lambda expressions, etc. So even
with the advent of template typedefs, I would hope true metafunctions
would not use them.]

On the other hand, if C++ had template typedefs, I would not want anyone
to have to write:

   void f() {
     recursive_variant< ... >::type v;

That recursive_variant is a metafunction is an implementation detail.
Thus, it is a mistake, IMO, to expose this implementation detail to the
user simply because of a deficiency in C++.

In contrast, a name like 'make_recursive_variant' explicitly indicates a
metafunction. Invoking this metafunction via ::type is no longer an
implementation detail but rather integral to the metafunction idiom.

Another way to think of it is as an issue of backwards compatibility.
Though it may be less _useful_ once template typedefs are standardized,
make_recursive_variant would still make _sense_ as a metafunction. I
don't think the same could be said of recursive_variant.

So to make a long response short, I don't think this is just an issue of
users needing to "learn to deal" with the metafunction idiom. Instead, I
think it's a question of whether it is appropriate to hijack the
metafunction idiom as a workaround.

Of course, I would be interested in your (or anyone else's) feedback on
this issue.


Boost list run by bdawes at, gregod at, cpdaniel at, john at