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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-25 08:35:47

From: "Eric Friedman" <ebf_at_[hidden]>
> "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

No, the analogy is flawed. In a pure functional language, 1.1 is a no-op,
since f() and g() aren't allowed to have side effects... this is what I
meant by "invokes code." It has no equivalent.

condition? f(): g()

or (in a statement form)

if(condition) return f(); else return g();

are analogous to 1.2.