[boost] Re: [variant] Important syntax changes

From: Andy Little (andy_at_[hidden])
Date: 2003-11-12 04:12:52

Hi

"Eric Friedman" <ebf_at_[hidden]> wrote in message
news:3FB1B292.8060504_at_users.sourceforge.net...
> David Abrahams wrote:
>
> > Eric Friedman <ebf_at_[hidden]> writes:
> >
> >
> >>>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.

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;

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

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;

(steering clear of the name metafunction as I may be using incorrectly )
with the  metawidget returning a value the obvious choice is "_v"

            MyWidget_v<X,Y,Z>::value;

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

As a newbie to metafunctions I find the "make_x" style odd. I dont want to
"make" anything.
 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.

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

Andy Little