[boost] Re: [variant] Important syntax changes

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
>>>(http://www.boost.org/more/generic_programming.html#object_generator).
>>
>>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.

Thanks,
Eric