[boost] Re: Rename mpl::if_ to mpl::select_if?

From: Eric Friedman (ebf_at_[hidden])
Date: 2002-07-24 23:04:02

"Peter Dimov" <pdimov_at_[hidden]> wrote:
> From: "Eric Friedman" <ebf_at_[hidden]>
> > The following excerpt is from a private conversation with Aleksey:
> >
> > > > [Eric]
> > > > Any possibility that if_ will return in name to select_if? I find
> > > > select_if to be a superior name for the following reasons:
> > > >
> > > >   if_ is visually distracting; OTOH select_if is visually-similar to
> >
> > > > apply_if.
> > > >   if_ is a bad analogy to runtime C++. In runtime C++ the if keyword
> >
> > > > invokes code, ?: operator selects a value.
>
> In compile time C++, nothing invokes code, and everything selects a value.
> It's a pure functional language.

That's why I used the word "analogy". Most of MPL is based upon analogiy to
runtime C++; for example, even though as you say "nothing invokes code",
mpl::apply is an analogy to function invocation. That is, mpl::apply<f, x,
y>::type recalls f(x,y); in my mind -- which I do not believe is accidental
<g>.

So in the same way, I see the following runtime code (example 1):

  if (condition) f(); else g(); // 1.1

as analogous to:

  mpl::apply_if<condition, f, g>::type // 1.2

While I see the following runtime code (example 2):

  condition ? x : y; // 2.1

as analogous to (and here is my point):

  mpl::if_<condition, x, y>::type // 2.2

As David Abrahams points out, this trailing-underscore type-naming
convention is to allow a keyword-like name to be used in a user-defined
context. Yet while 2.2 employs a type named in this convention (i.e. if_),
2.1 does not have the if keyword in sight. Meanwhile, 1.1 *does* employ the
if keyword, suggesting that in fact 2.2 is analogous to 1.1 (which is very
far from true).

For these reasons, I think the mpl::if_ name may be an unnecessary point of
confusion for new users of MPL and restate my proposal that the
mpl::select_if name be restored.

Please feel free to argue ;)

Thanks,
Eric