[boost] Re: [variant] Important syntax changes

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-11-12 18:33:10

Andy Little wrote:
> Hi
> 
> The metafunction naming style that instantly came to mind for me
>  and honestly thought was in use ( as a newbie to MPL) was to add a '_t'
>  to the name, hence
> 
>          MyWidget_t<X,Y,Z>::type;

This is not the convention used by MPL.

> the precedent for this is the "wchar_t", "time_t","clock_t" etc types.

These types you cite as 'precedent' are not metafunctions. They are 
regular types. That is, you *never* write:

   wchar_t::type
   time_t::type
   clock_t::type

> Its also much shorter to type and the suffix reflects the position of the
> ::type in the useage.
> The user feels a natural urge to 'fill in' the "_t" with a "::type".
> of course you could do more typing, but redundant typing is redundant :-)
> 
>     MyWidget_type<X,Y,Z>::type;

I don't see how either the name MyWidget_t or MyWidget_type suggests to 
the user a metafunction (i.e., that a trailing ::type is required). As I 
wrote in my previous post, I believe this is because they are nouns.

A noun suggests a completed state, whereas what needs to be conveyed is 
a transformation (i.e., a function from one type to another).

> (steering clear of the name metafunction as I may be using incorrectly )

I think you may be.

> with the  metawidget returning a value the obvious choice is "_v"
> 
>             MyWidget_v<X,Y,Z>::value;

I don't think this is obvious. I don't even think I've seen it before.

> this extends the  "wchar_t" precedent of course  to fit the MPL world

Again, I think you're off with your 'precedent' here. Further, adding a 
trailing _v is not an MPL convention.

> As a newbie to metafunctions I find the "make_x" style odd. I dont want to
> "make" anything.

Yes, you do. You want to make a recursive variant type. As I said, 
though, I'm not committed to "make"; I just haven't seen another verb 
that's better.

>  That suggests run time hence "weak" from an MPL point of view. Hopefully as
> a user by the time I use it it has already been "made"
> I see MPL types  as "hard immutable" things  "metamorphed", "ground from"
> ,"chiselled f rom" my arguments at compile time,
> unlike the weak and wibbly wobbly entities of runtime.

I think the trailing ::type is a good indicator that there is no runtime 
behavior here.

> Apologies for wading in... but I feel much better with that off my chest :-)

No problem, but what I'm aiming for is to choose a name that is most 
likely to prevent misuse that is difficult to identify. I'd argue even 
an ambiguous name is better than one that is falsely unambiguous: the 
the former will quickly send the user to the documentation; the latter 
will leave the user confused.

So again: "I plan to leave the names as make_recursive_variant, etc. 
unless someone proposes another verb phrase that is better."

Thanks,
Eric