<html>
	<head>
		<title>A Proposal to Add an Enhanced Binder to the Library Technical Report (revision 1)</title>
		<meta content="http://schemas.microsoft.com/intellisense/ie5" name="vs_targetSchema">
		<meta http-equiv="Content-Language" content="en-us">
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	</head>
	<body bgColor="#ffffff">
                <address>Document number: N1455=03-0038</address>
		<ADDRESS>Revises document number: N1438=03-0020</ADDRESS>
		<ADDRESS>Programming Language C++, Library Subgroup</ADDRESS>
		<ADDRESS>&nbsp;</ADDRESS>
		<ADDRESS>Peter Dimov &lt;<A href="mailto:pdimov@mmltd.net">pdimov@mmltd.net</A>&gt;</ADDRESS>
		<ADDRESS>Douglas Gregor &lt;<A href="mailto:gregod@cs.rpi.edu">gregod@cs.rpi.edu</A>&gt;</ADDRESS>
		<ADDRESS>Jaakko Järvi &lt;<A href="mailto:jajarvi@cs.indiana.edu">jajarvi@cs.indiana.edu</A>&gt;</ADDRESS>
		<ADDRESS>Gary Powell &lt;<A href="mailto:powellg@amazon.com">powellg@amazon.com</A>&gt;</ADDRESS>
		<ADDRESS>&nbsp;</ADDRESS>
		<ADDRESS>April 10, 2003</ADDRESS>
		<h1>A Proposal to Add an Enhanced Binder to the Library Technical Report (revision 1)</h1>
		<h2>I. Motivation</h2>
		<p>The standard C++ library supports and encourages a powerful programming style 
			that relies on a combination of generic algorithms and small utility components 
			known as function objects, used to adapt algorithm behavior. A collection of 
			standard algorithms that cover a wide range of practical problems is provided 
			by the standard header <code>&lt;algorithm&gt;</code> . The standard header <code>&lt;functional&gt;</code>
			provides some commonly used function objects, and algorithms are able to work 
			with ordinary C++ functions as well. Nevertheless, the problem at hand often 
			calls for a slightly different function object. For example, the order of the 
			two parameters may need to be reversed, one of the parameters may need to have 
			a specific value, or the desired functionality may be already present but 
			provided by a member function.</p>
		<P>One obvious solution is to write a new function or a function object by hand. 
			This is often tedious, and the result is typically difficult to reuse, being 
			tightly specialized to handle one particular situation. The standard library 
			recognizes the need of function object creation tools, and attempts to provide 
			a solution in the form of the function object <EM>adaptors</EM> <code>bind1st</code>,
			<code>bind2nd</code>, <code>ptr_fun</code>, <code>mem_fun</code>, and <code>mem_fun_ref</code>.</P>
		<P>The standard adaptors <code>bind1st</code> and <code>bind2nd</code> have a 
			number of limitations. They do not support function objects with reference 
			arguments well, they only support <EM>adaptable function objects</EM> forcing 
			users to adapt pointers to functions and pointers to member functions manually 
			using <code>ptr_fun</code>, <code>mem_fun</code>, or <code>mem_fun_ref</code> as 
			appropriate, and they only produce unary function objects given a binary 
			function object. Some of these problems are described in [<A href="#Simonis00">Simonis00</A>]. 
			[<A href="#Jarvi00">Järvi00</A>], [<A href="#Rodgers00">Rodgers00</A>] and [<A href="#Williams01">Williams01</A>] 
			offer solutions.</P>
		<P>Function object composition libraries ([<A href="#Josuttis00">Josuttis00</A>], [<A href="#SGI97a">SGI97a</A>], 
			[<A href="#SGI97b">SGI97b</A>]) provide another useful tool for function object 
			creation.</P>
		<P>Lambda libraries ([<A href="#Boost02">Boost02</A>], [<A href="#Guzman02">Guzman02</A>]) 
			use operator overloading and expression template techniques to go even further. 
			They provide a powerful framework that is not constrained to pre-existing 
			function objects. As a result, these libraries can duplicate most of the 
			functionality of the existing facilities provided in <code>&lt;functional&gt;</code>, 
			while offering a familiar syntax built on C++ expressions. However, due to 
			language limitations, most notably lack of a suitable <code>typeof</code> operator 
			[<A href="#Stroustrup00">Stroustrup00</A>], such a library is not implementable 
			in its "perfect" form, although the existing implementations use increasingly 
			sophisticated heuristics to approximate <code>typeof</code>. Furthermore, it 
			should be noted that the field is still a subject of active research [<A href="#Jarvi03">Järvi03</A>].</P>
		<P>This document proposes an enhanced binder facility that:</P>
		<UL>
			<LI>
				Supports but does not require <EM>adaptable</EM>
			function objects;
			<LI>
				Supports functions, function pointers, and pointers to members (including data 
				members) natively, without requiring the use of <code>ptr_fun</code>, <code>mem_fun</code>, 
				and <code>mem_fun_ref</code>;
			<LI>
			Supports functions with reference arguments;
			<LI>
			Supports function objects with arbitrary arity (subject to 
			implementation-imposed constraints);
			<LI>
			Supports references to noncopyable or stateful function objects;
			<LI>
			Can bind an arbitrary argument of the target function object to an arbitrary 
			value, or reference;
			<LI>
			Can re-route, reorder, and ignore input arguments;
			<LI>
			Supports function object composition via the use of nested subexpressions;
			<LI>
			Delivers exceptional expressive power using a simple and consistent syntax;
			<LI>
			Fills an obvious gap in the current standard library, as reflected by the 
			number of independent solutions to various parts of the problem;
			<LI>
			Requires no language support;
			<LI>
				Reflects existing practice with several years of refinement and use [<A href="#Jarvi99">Järvi99</A>] 
				[<A href="#Boost01">Boost01</A>] [<A href="#Boost02">Boost02</A>];
			<LI>
			Has an open architecture and provides a standard interface for extensibility;
			<LI>
				Naturally complements the polymorphic function object wrapper proposed in [<A href="#Gregor02">Gregor02</A>];
			<LI>
				Is recommended as the standard way to pass arguments to <A href="http://www.boost.org/libs/thread/">
					Boost.Threads</A> thread routines [<A href="#Kempf02">Kempf02</A>].</LI></UL>
		<h3>A. Examples</h3>
		<p>The following example demonstrates the basic functionality of <code>bind</code>:</p>
		<pre>
double m; double s; double x;
double gauss(double x, double mean, double std);

bind(gauss, _1, m, s); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // #1
bind(gauss, x, _1, _2); &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// #2
bind(gauss, bind(std::rand), m, s) // #3
</pre>
		<p>Line <code>#1</code> applies the <code>gauss</code> function partially, binding 
			the parameters <code>mean</code> and <code>std</code> to <code>m</code> and <code>s</code>, 
			respectively, resulting in a unary function. When called with an actual 
			argument, say <code>x</code>, the special placeholder argument <code>_1</code> is 
			replaced by <code>x</code> and the <code>gauss</code> function is invoked with <code>
				x</code>, <code>m</code>, and <code>s</code>. Hence, <code>bind(gauss, _1, m, 
				s)(x)</code> computes the same result as <code>gauss(x, m, s)</code>. In 
			line <code>#2</code> we are using another placeholder variable <code>_2</code>, 
			and the result is a binary function. The expression in line <code>#3</code> shows 
			how function compositions can be expressed as nested <code>bind</code> functions. 
			Here, the result is a zero-argument function that calls <code>gauss(std::rand(), m, 
				s)</code> on every invocation.</p>
		<p>A simple demonstration of <code>bind</code> interacting with a standard 
			algorithm is given by the following example:</p>
		<pre>
class Employee
{
public:

  int number() const;
};

std::vector&lt;Employee&gt; v;

// sort by employee ID number

std::sort(v.begin(), v.end(), 
  bind(std::less&lt;int&gt;(),
    bind(&amp;Employee::number, _1),
    bind(&amp;Employee::number, _2)
  )
);
</pre>
		<p>Note that the syntax of the <code>bind</code> calls doesn't change if <code>number</code>
			is made a public data member of <code>Employee</code>.</p>
		<P>Finally, an example of <code>bind</code> and <code>function</code> [<A href="#Gregor02">Gregor02</A>] 
			being used together:</P>
		<pre>
class button
{
public:

    function&lt; void() &gt; onClick;
};

class player
{
public:

    void play(bool m);
};

button playButton, stopButton;
player thePlayer;

void connect()
{
    playButton.onClick = bind(&amp;player::play, &amp;thePlayer, true);
    stopButton.onClick = bind(&amp;player::play, &amp;thePlayer, false);
}
</pre>
		<h2>II. Impact On the Standard</h2>
		<p>This proposal is almost a pure library extension. It proposes changes to an 
			existing header, <code>&lt;functional&gt;</code>, but it does not require 
			changes to any standard classes or functions and it does not require changes to 
			any of the standard requirement tables.</p>
		<P>The proposal does not require any changes in the core language, although it 
			would benefit greatly from a solution to the forwarding problem [<A href="#Dimov02">Dimov02</A>] 
			or from a <code>typeof</code> extension [<A href="#Stroustrup02">Stroustrup02</A>]. 
			Two independent and widely used implementations exist [<A href="#Boost01">Boost01</A>] 
			[<A href="#Boost02">Boost02</A>].</P>
		<P>In order to transparently handle pointers to members as function objects, the 
			proposal depends on the pointer to member adaptor <code>mem_fn</code> [<A href="#Dimov03">Dimov03</A>].</P>
		<P>To allow users to indicate that a function object should store references 
			instead of values, this proposal depends on the auxilliary class template <code>reference_wrapper</code>
			[<A href="#Gregor03a">Gregor03a</A>].</P>
                <p>To deduce the return types of function object calls, the proposal depends on the <code>result_of</code> proposal [<a href="#Gregor03b">Gregor03b</a>].</p>
		<h2>III. Design Decisions</h2>
		<h3>A. Open and Closed Implementations</h3>
		<p>This proposal defines the class templates <code>is_placeholder</code> and <code>is_bind_expression</code>, 
			used by <code>bind</code> to recognize placeholders and nested subexpressions, 
			respectively.</p>
		<P>Open implementations honor user specializations of <code>is_placeholder</code> and
			<code>is_bind_expression</code>, allowing user extensibility. Closed 
			implementations do not.</P>
		<P>Existing implementations are closed. <A href="http://www.boost.org/libs/bind/">Boost.Bind</A>'s 
			primary goal has been portability to a wide range of compilers. The <code>bind</code>
			implementation in <A href="http://www.boost.org/libs/lambda/">Boost.Lambda</A> is 
			tightly integrated with the rest of the library. However, as standard 
			implementations of <code>bind</code> start becoming available, we firmly 
			believe that a public extension interface would benefit libraries that aim to 
			go beyond the functionality provided by <code>bind</code> [<A href="#Boost02">Boost02</A>] 
			[<A href="#Guzman02">Guzman02</A>]. Such libraries can even recognize each 
			other's function objects and placeholders through the standard interface 
			presented in this proposal.</P>
		<P>Therefore, this proposal requires an open implementation.</P>
		<h3>B. Unspecified Return Types and Placeholder Types</h3>
		<p>This proposal does not specify the return types of the various <code>bind</code> 
			overloads and the types of the placeholder variables. The exact types are 
			almost never needed, are too unwieldy to manipulate, and vary greatly between 
			existing implementations. For example, the innocent expression</p>
		<P><CODE>bind(&amp;X::f, &amp;x, _1)</CODE></P>
		<p>typically has a return type of</p>
		<p><code>boost::_bi::bind_t&lt;void, boost::_mfi::mf1&lt;void, X, int&gt;, 
				boost::_bi::list2&lt;boost::_bi::value&lt;X *&gt;, boost::arg&lt;1&gt; &gt; 
				&gt;</code></p>
		<p>in <A href="http://www.boost.org/libs/bind/">Boost.Bind</A> (the actual type may 
			vary across compilers), and</p>
		<p><code>boost::lambda::lambda_functor&lt;boost::lambda::lambda_functor_base&lt;boost::lambda::action&lt;3, 
				boost::lambda::function_action&lt;3, boost::lambda::detail::unspecified&gt; 
				&gt;, boost::tuples::tuple&lt;void (X::*const)(int), X * const, 
				boost::lambda::lambda_functor&lt; boost::lambda::placeholder&lt;1&gt; &gt; 
				const, boost::tuples::null_type, boost::tuples::null_type, 
				boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, 
				boost::tuples::null_type, boost::tuples::null_type&gt; &gt; &gt;</code></p>
		<p>in <A href="http://www.boost.org/libs/lambda/">Boost.Lambda</A>.</p>
		<h3>C. Placeholders Defined in a Nested Namespace</h3>
		<p>The placeholder variables <code>_1</code>, <code>_2</code>, ... are defined in a 
			nested namespace, <code>std::placeholders</code>, in order to allow a single</p>
		<pre>using namespace std::placeholders;</pre>
		<P>directive to make them visible without qualification without bringing the whole 
			namespace <code>std</code> into scope.</P>
		<P>This proposal diverges from existing implementations in this regard. <A href="http://www.boost.org/libs/bind/">
				Boost.Bind</A> defines its placeholders in a global unnamed namespace. <A href="http://www.boost.org/libs/lambda/">
				Boost.Lambda</A> defines both the <code>bind</code> function templates and 
			the placeholders in the same namespace, <code>boost::lambda</code>.</P>
		<h3>D. Optional <code>DefaultConstructible</code> and <code>Assignable</code> Requirements</h3>
		<p>Some libraries create iterators that store function objects [<A href="#Siek00">Siek00</A>]. 
			As most iterators need to be <code>DefaultConstructible</code> and <code>Assignable</code>, 
			this proposal requires implementations to document whether function objects 
			produced by <code>bind</code> conform to these requirements.</p>
		<P><A href="http://www.boost.org/libs/bind/">Boost.Bind</A> has <code>DefaultConstructible</code>
			and <CODE>Assignable</CODE> placeholders, and produces <code>DefaultConstructible</code>
			and/or <code>Assignable</code> function objects when all arguments to <code>bind</code>
			are <code>DefaultConstructible</code> and/or <code>Assignable</code>.</P>
		<P><A href="http://www.boost.org/libs/lambda/">Boost.Lambda</A> overloads the 
			assignment operator to create a lambda expression, and its function objects and 
			placeholders aren't <code>Assignable</code>.</P>
		<h3>E. <code>result_type</code> Requirement</h3>
		<p>It is generally accepted as good practice for a function object type <code>F</code>
			to define a nested typedef <code>F::result_type</code> that denotes the return 
			type of <code>F::operator()</code>. Return type inference is difficult in the 
			current language, and many libraries rely on <code>result_type</code> instead. 
			Additionally, modern programming techniques allow the existence of <code>result_type</code>
			to be determined at compile time. The presence of <code>result_type</code> can 
			even be used to enable an overload only for function objects.</p>
		<P>Therefore, this proposal requires implementations to define <code>result_type</code>
			when it can be determined.</P>
		<P>As a side note, as the current language allows fairly acceptable forwarding [<A href="#Dimov02">Dimov02</A>], 
			the argument type typedefs described in 20.3/5 are rarely, if ever, required.</P>
		<h3>F. Arity Errors</h3>
		<p>In our experience, one of the most common user errors is invoking <code>bind</code>
			with a number of arguments that does not correspond to the arity of the 
			function object being bound. In particular, it is easy to forget that pointers 
			to members have an additional implicit argument that identifies the object.</p>
		<P>It is important to detect these mistakes as early as possible, at the point 
			where <code>bind</code> is called, hence the "<code>f(w1, ..., w<em>m</em>)</code>
			must be a valid expression" requirement in the proposed text.</P>
		<P><A href="http://www.boost.org/libs/bind/">Boost.Bind</A> implements this early 
			check by using separate overloads for function pointers and member pointers.</P>
		<h3>G. Dependency on <code>mem_fn</code></h3>
		<p>This proposal specifies the behavior of <code>bind</code> with a pointer to 
			member as a first argument in terms of <code>mem_fn</code> [<A href="#Dimov03">Dimov03</A>] 
			to avoid unnecessary duplication. Within the scope of this proposal, 
			implementations are not required to provide, or actually call, <code>mem_fn</code>.</p>
		<h3>H. <code>bind</code> Uses Pass by Value</h3>
		<p>The <code>bind</code> specification uses pass by value signatures to take 
			advantage of the automatic function- and array-to-pointer decay, but the number 
			of copies that is made for each argument is not specified. This is consistent 
			with the resolution of <A href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#181">
				Library Issue 181</A>.</p>
		<P>The additional <code>CopyConstructible</code> requirement is imposed to disallow 
			arguments of types such as <code>std::auto_ptr</code> that implement 
			destructive copy.</P>
		<h3>I. Qualifier Propagation</h3>
		<p>As the arguments passed to <code>bind</code> are stored in the returned function 
			object, and are part of its state, they should inherit its cv-qualifiers, if 
			any.</p>
                
		<h3>J. Limits of Existing Implementations</h3>
		<p><A href="http://www.boost.org/libs/bind/">Boost.Bind</A> defines nine 
			placeholders, from <code>_1</code> to <code>_9</code>, and supports up to nine 
			arguments (<EM>N</EM> = 9).</p>
		<P><A href="http://www.boost.org/libs/lambda/">Boost.Lambda</A> defines three 
			placeholders, <code>_1</code>, <code>_2</code>, and <code>_3</code>, and also 
			supports up to nine arguments (<EM>N</EM> = 9). A future release will increase 
			the number of placeholders substantially.</P>
		<h2>IV. Proposed Text</h2>
		<h3>A. Additions to header &lt;functional&gt; synopsis (20.3)</h3>
		<pre>    template&lt;class T&gt; struct is_bind_expression;
    template&lt;class T&gt; struct is_placeholder;

    template&lt;class F&gt; <em>unspecified</em> bind(F f);
    template&lt;class R, class F&gt; <em>unspecified</em> bind(F f);

    template&lt;class F, class A1&gt; <em>unspecified</em> bind(F f, A1 a1);
    template&lt;class R, class T, class A1&gt; <em>unspecified</em> bind(R T::* pm, A1 a1);
    template&lt;class R, class F, class A1&gt; <em>unspecified</em> bind(F f, A1 a1);

    // for all positive integers <em>n</em> in [2, <em>N</em>)

    template&lt;class F, class A1, ..., class A<em>n</em>&gt; <em>unspecified</em> bind(F f, A1 a1, ..., A<em>n</em> a<em>n</em>);
    template&lt;class R, class T, class A1, ..., class A<em>n</em>&gt; <em>unspecified</em> bind(R T::* pmf, A1 a1, ..., A<em>n</em> a<em>n</em>);
    template&lt;class R, class F, class A1, ..., class A<em>n</em>&gt; <em>unspecified</em> bind(F f, A1 a1, ..., A<em>n</em> a<em>n</em>);
    
    namespace placeholders {
      <em>// M is the implementation-defined number of placeholders</em>
      extern <em>unspecified</em> _1;
      extern <em>unspecified</em> _2;
                  .
                  .
                  .
      extern <em>unspecified</em> _M;
    }
</pre>
		<h3>B. Class template <code>is_bind_expression</code></h3>
		<pre>  namespace std {
    template&lt;class T&gt; struct is_bind_expression {
      static const bool value = <em>unspecified</em>;
    };
  }
</pre>
		<p><code>is_bind_expression</code> can be used to detect function objects generated 
			by <code>bind</code>. <code>bind</code> uses <code>is_bind_expression</code> to 
			detect subexpressions. The template can be specialized by users to indicate 
			that a type should be treated as a subexpression in a <code>bind</code> call.</p>
		<pre>      static const bool value;
</pre>
		<p><code>true</code> if <code>T</code> is a type returned from <code>bind</code>, <code>
				false</code> otherwise.</p>
		<h3>C. Class template <code>is_placeholder</code></h3>
		<pre>  namespace std {
    template&lt;class T&gt; struct is_placeholder {
      static const int value = <em>unspecified</em>;
    };
  }
</pre>
		<p><code>is_placeholder</code> can be used to detect the standard placeholders <code>_1</code>,
			<code>_2</code>, and so on. <code>bind</code> uses <code>is_placeholder</code> to 
			detect placeholders. The template can be specialized by users to indicate a 
			placeholder type.</p>
		<pre>      static const int value;
</pre>
		<p><code>value is <em>N</em> if <code>T</code> is the type of <code>std::placeholders::_<em>N</em></code>, 0 
			otherwise.</p>

		<h3>D. <code>bind</code></h3>
		<p>The function <code>λ(x)</code> is defined as <code>x.get()</code> when <code>x</code>
			is of type <code>reference_wrapper&lt;F&gt;</code> for some <code>F</code>, <code>x</code>
			otherwise.</p>
		<p>The function <code>µ(x, v<SUB>1</SUB>, ..., v<em><SUB>m</SUB></em>)</code>
			<code>x</code> is of type <code>X</code>, 
			and <code>k</code> is <code>is_placeholder&lt;X&gt;::value</code>, is defined 
			as:</p>
		<UL>
			<LI>
				<code>x.get()</code>, when <code>X</code> is a <code>reference_wrapper&lt;T&gt;</code>
				for some <code>T</code>;
			<LI>
				<code>v<SUB>k</SUB></code>, when <code>k != 0</code>;
			<LI>
				<code>x(v<sub>1</sub>, ..., v<sub>m</sub>)</code>, when <code>is_bind_expression&lt;X&gt;::value</code>
				is <code>true</code>;
			<LI>
				<code>x</code> otherwise.</LI></UL>
		<P>A function object <code>f</code> of type <code>F</code> is called <EM>simple</EM>, 
			if <code>f</code> is a pointer to a function with C++ linkage or <code>F::result_type</code> is a type.</p>
		<P>The maximum number of supported arguments (<EM>N</EM> in the synopsis) is 
			implementation defined. Implementations are allowed to define additional, more 
			specialized, <code>bind</code> overloads, or to fold the pointer to member 
			overload into the general function template, as long as the behavior of the <code>bind</code>
			calls is unchanged.</P>

<p>Given a list of arguments <code>a1</code>,
        <code>a2</code>, ..., <code>a<em>n</em></code>, a function
          object <code>h</code> as returned from a call to
          <code>bind</code>, and the definition:</p>
<pre>
struct forward {
  template&lt;typename T1, typename T2, ..., typename T<em>n</em>&gt;
    void operator()(T1&amp;, T2&amp;, ...,T<em>n</em>&amp;);
};
        </pre>
  <p> If the expression <code>forward()(a1, a2, ...,
            a<em>n</em>)</code> is well-formed, then the expression
          <code>h(a1, a2, ..., a<em>n</em>)</code> must be well-formed
          and must have the same argument passing semantics as <code>forward()(a1, a2, ...,
            a<em>n</em>)</code>. [ Note - Implementations are encouraged to support argument
        forwarding for non-const temporaries - end note]</p>


		<pre>    template&lt;class F&gt; <em>unspecified</em> bind(F f);
</pre>
		<p><b>Requires:</b> <code>F</code> must be <code>CopyConstructible</code>. <code>λ(f)()</code>
			must be a valid expression. If <code>f</code> is not a <EM>simple</EM> function 
			object, the behavior is implementation defined.</p>
		<p><b>Returns:</b> A function object <code>g</code> of an unspecified <code>CopyConstructible</code>
			type <code>G</code> such that the expression <code>g(v1, ..., v<sub>m</sub>)</code>
			is
        equivalent to <code>λ(f)()</code>. The type of the expression
        <code>g(v1,
          ..., v<sub>m</sub>)</code> is <code>result_of&lt;R()&gt;::type</code>
        where <code>R</code> is the type of <code>λ(f)</code>.
			If the function application is made via a cv-qualified reference to, or copy 
			of, <code>g</code>, the same cv-qualifiers are applied to <code>f</code> before 
			the evaluation. When <code>f</code> is a pointer to a function with C++ 
			linkage, <code>G::result_type</code> is defined as the return type of the <code>f</code>. 
			When <code>F::result_type</code> is defined, <code>G::result_type</code> is 
			defined as the same type.</p>
		<p><b>Throws:</b> nothing unless the copy constructor of <code>f</code> throws an 
			exception.</p>
		<p><b>Notes:</b> Implementations are allowed to impose an upper limit on <em>m</em> 
			(typically one more than the number of supported placeholders). It is implementation 
			defined whether <code>G</code> is <code>Assignable</code> or <code>DefaultConstructible</code>.</p>
		<pre>    template&lt;class R, class F&gt; <em>unspecified</em> bind(F f);
</pre>
		<p><b>Requires:</b> <code>F</code> must be <code>CopyConstructible</code>. <code>λ(f)()</code>
			must be a valid expression convertible to <code>R</code>.</p>
		<p><b>Returns:</b> A function object <code>g</code> of an unspecified <code>CopyConstructible</code>
			type <code>G</code> such that the expression <code>g(v1, ..., v<sub>m</sub>)</code>
			is equivalent to <code>λ(f)()</code>, 
			implicitly converted to <code>R</code>. If the function application is made via 
			a cv-qualified reference to, or copy of, <code>g</code>, the same cv-qualifiers 
			are applied to <code>f</code> before the evaluation. <code>G::result_type</code>
			is defined as <code>R</code>.</p>
		<p><b>Throws:</b> nothing unless the copy constructor of <code>f</code> throws an 
			exception.</p>
		<p><b>Notes:</b> Implementations are allowed to impose an upper limit on <em>m</em>. 
			It is implementation defined whether <code>G</code> is <code>Assignable</code> or
			<code>DefaultConstructible</code>.</p>
		<pre>    template&lt;class F, class A1&gt; <em>unspecified</em> bind(F f, A1 a1);
</pre>
		<p><b>Requires:</b> <code>F</code> and <code>A1</code> must be <code>CopyConstructible</code>.
			<code>λ(f)(w1)</code> must be a valid expression for some value <code>w1</code>. 
			If <code>f</code> is not a <EM>simple</EM> function object, the behavior is 
			implementation defined.</p>
		<p><b>Returns:</b> A function object <code>g</code> of an unspecified <code>CopyConstructible</code>
			type <code>G</code> such that the expression <code>g(v1, ..., v<sub>m</sub>)</code>
			is equivalent to <code>λ(f)(µ(a1, v1, 
				..., v<sub>m</sub>))</code>. The type
        of the expression <code>g(v1,
          ..., v<sub>m</sub>)</code> is <code>result_of&lt;R(T)&gt;::type</code>
        where <code>R</code> is the type of <code>λ(f)</code> and
        <code>T</code> is the type of <code>µ(a1, v1, 
				..., v<sub>m</sub>)</code>. If the function application is made via a 
			cv-qualified reference to, or copy of, <code>g</code>, the same cv-qualifiers 
			are applied to <code>f</code> and <code>a1</code> before the evaluation. When <code>
				f</code> is a pointer to a function with C++ linkage, <code>G::result_type</code>
			is defined as the return type of the <code>f</code>. When <code>F::result_type</code>
			is defined, <code>G::result_type</code> is defined as the same type.</p>
		<p><b>Throws:</b> nothing unless the copy constructors of <code>f</code> or <code>a1</code>
			throw an exception.</p>
		<p><b>Notes:</b> Implementations are allowed to impose an upper limit on <em>m</em>. 
			It is implementation defined whether <code>G</code> is <code>Assignable</code> or
			<code>DefaultConstructible</code>.</p>
		<pre>    template&lt;class R, class T, class A1&gt; <em>unspecified</em> bind(R T::* pm, A1 a1);
</pre>
		<p><b>Requires:</b> <code>pm</code> must be a pointer to data member or pointer to 
			a member function taking no arguments.</p>
		<p><b>Returns:</b> <code>bind(mem_fn(pm),
          a1)</code>.</p>



		<pre>    template&lt;class R, class F, class A1&gt; <em>unspecified</em> bind(F f, A1 a1);
</pre>
		<p><b>Requires:</b> <code>F</code> and <code>A1</code> must be <code>CopyConstructible</code>.
			<code>λ(f)(w1)</code>, for some value <code>w1</code>, must be a valid 
			expression convertible to <code>R</code>.</p>
		<p><b>Returns:</b> A function object <code>g</code> of an unspecified <code>CopyConstructible</code>
			type <code>G</code> such that the expression <code>g(v1, ..., v<sub>m</sub>)</code>
			is equivalent to <code>λ(f)(µ(a1, v1, 
				..., v<sub>m</sub>))</code>, implicitly converted to <code>R</code>. If the 
			function application is made via a cv-qualified reference to, or copy of, <code>g</code>, 
			the same cv-qualifiers are applied to <code>f</code> and <code>a1</code> before 
			the evaluation. <code>G::result_type</code> is defined as <code>R</code>.</p>
		<p><b>Throws:</b> nothing unless the copy constructors of <code>f</code> or <code>a1</code>
			throw an exception.</p>
		<p><b>Notes:</b> Implementations are allowed to impose an upper limit on <em>m</em>. 
			It is implementation defined whether <code>G</code> is <code>Assignable</code> or
			<code>DefaultConstructible</code>.</p>
		<pre>    template&lt;class F, class A1, ..., class A<em>n</em>&gt; <em>unspecified</em> bind(F f, A1 a1, ..., A<em>n</em> a<em>n</em>);
</pre>
		<p><b>Requires:</b> <code>F</code> and <code>A<em>i</em></code> must be <code>CopyConstructible</code>.
			<code>λ(f)(w1, ..., w<em>n</em>)</code> must be a valid expression for some 
			values <code>w<em>i</em></code>. If <code>f</code> is not a <EM>simple</EM> function 
			object, the behavior is implementation defined.</p>
		<p><b>Returns:</b> A function object <code>g</code> of an unspecified <code>CopyConstructible</code>
			type <code>G</code> such that the expression <code>g(v1, ..., v<sub>m</sub>)</code>
			is equivalent to <code>λ(f)(µ(a1, v1, 
				..., v<sub>m</sub>), ...,
          µ(a<em>n</em>, v1, ..., v<sub>m</sub>))</code>. 

The type of the expression <code>g(v1,
          ..., v<sub>m</sub>)</code> is <code>result_of&lt;R(T1, T2,
          ..., T<em>n</em>)&gt;::type</code>
        where <code>R</code> is the type of <code>λ(f)</code> and
        each <code>T<em>i</em></code> is the type of <code>µ(a<em>i</em>, v1, 
				..., v<sub>m</sub>)</code>. 

			If the function application is made via a cv-qualified reference to, or copy 
			of, <code>g</code>, the same cv-qualifiers are applied to <code>f</code> and <code>a<em>i</em></code>
			before the evaluation. When <code>f</code> is a pointer to a function with C++ 
			linkage, <code>G::result_type</code> is defined as the return type of the <code>f</code>. 
			When <code>F::result_type</code> is defined, <code>G::result_type</code> is 
			defined as the same type.</p>
		<p><b>Throws:</b> nothing unless the copy constructors of <code>f</code> or <code>a<em>i</em></code>
			throw an exception.</p>
		<p><b>Notes:</b> Implementations are allowed to impose an upper limit on <em>m</em>. 
			It is implementation defined whether <code>G</code> is <code>Assignable</code> or
			<code>DefaultConstructible</code>.</p>


		<pre>    template&lt;class R, class T, class A1, ..., class A<em>n</em>&gt; <em>unspecified</em> bind(R T::* pmf, A1 a1, ..., A<em>n</em> a<em>n</em>);
</pre>
		<p><b>Requires:</b> <code>pmf</code> must be a pointer to a member function taking <code>
				<em>n</em>-1</code> arguments.</p>
		<p><b>Returns:</b> <code>bind(mem_fn(pmf), a1, ..., a<em>n</em>)</code>.</p>
		<pre>    template&lt;class R, class F, class A1, ..., class A<em>n</em>&gt; <em>unspecified</em> bind(F f, A1 a1, ..., A<em>n</em> a<em>n</em>);
</pre>
		<p><b>Requires:</b> <code>F</code> and <code>A<em>i</em></code> must be <code>CopyConstructible</code>.
			<code>λ(f)(w1, ..., w<em>n</em>)</code>, for some values <code>w<em>i</em></code>, 
			must be a valid expression convertible to <code>R</code>.</p>
		<p><b>Returns:</b> A function object <code>g</code> of an unspecified <code>CopyConstructible</code>
			type <code>G</code> such that the expression <code>g(v1, ..., v<sub>m</sub>)</code>
			is equivalent to <code>λ(f)(µ(a1, v1, 
				..., v<sub>m</sub>), ..., µ(a<em>n</em>, v1, ..., v<sub>m</sub>))</code>, 
			implicitly converted to <code>R</code>. If the function application is made via 
			a cv-qualified reference to, or copy of, <code>g</code>, the same cv-qualifiers 
			are applied to <code>f</code> and <code>a<em>i</em></code> before the 
			evaluation. <code>G::result_type</code> is defined as <code>R</code>.</p>
		<p><b>Throws:</b> nothing unless the copy constructors of <code>f</code> or <code>a<em>i</em></code>
			throw an exception.</p>
		<p><b>Notes:</b> Implementations are allowed to impose an upper limit on <em>m</em>. 
			It is implementation defined whether <code>G</code> is <code>Assignable</code> or
			<code>DefaultConstructible</code>.</p>
		<h3>E. Placeholders</h3>
		<pre>  namespace std {
    namespace placeholders {
      extern <em>unspecified</em> _1;
      extern <em>unspecified</em> _2;
      extern <em>unspecified</em> _3;
      // implementation defined number of additional placeholders
    }
  }
</pre>
		<p>All placeholder types are <code>DefaultConstructible</code> and <code>CopyConstructible</code>, 
			and their default constructors and copy constructors do not throw. It is 
			implementation defined whether placeholder types are <code>Assignable</code>. <code>
				Assignable</code> placeholders' copy assignment operators do not throw 
			exceptions.</p>

<h3>F. Implementation quantities</h3>
<ul>
  <li>Number of placeholder types in namespace <code>std::placeholders</code> [9].</li>
  <li>Number of arguments that can be passed to a <code>bind</code> function object [10].</li>
</ul>

<h2>Revision history</h2>
<p>Revision 1:
<ul>
  <li>Added implementation quantities</li>
  <li>Specify argument forwarding behavior</li>
  <li>Use <code>result_of</code> exclusively for return type deduction.</li>
</ul>
		<h2>V. References</h2>
		<p>[<a name="Boost01">Boost01</a>] Boost.Bind library, September 2001. Available 
			online at <a href="http://www.boost.org/libs/bind/">http://www.boost.org/libs/bind/</a></p>
		<p>[<a name="Boost02">Boost02</a>] Boost.Lambda library, April 2002. Available 
			online at <a href="http://www.boost.org/libs/lambda/">http://www.boost.org/libs/lambda/</a></p>
		<p>[<a name="Dimov02">Dimov02</a>] Peter Dimov, Howard E. Hinnant, Dave Abrahams, <i>The 
				Forwarding Problem: Arguments</i>, C++ committee document N1385=02-0043, 
			September 2002. Available online at <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm">
				http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm</a></p>
		<p>[<a name="Dimov03">Dimov03</a>] Peter Dimov, <i>A Proposal to Add an Enhanced Member 
				Pointer Adaptor to the Library Technical Report</i>, C++ committee document 
			N1432=03-0014, February 2003. Available online at <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1432.htm">
				http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1432.htm</a></p>
		<p>[<a name="Gregor02">Gregor02</a>] Douglas Gregor, <em>A Proposal to add a 
				Polymorphic Function Object Wrapper to the Standard Library</em>, C++ 
			committee document N1402=02-0060, October 2002. Available online at <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1402.htm">
				http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1402.htm</a></p>
		<p>[<a name="Gregor03a">Gregor03a</a>] Douglas Gregor, <em>A Proposal to Add a 
				Reference Wrapper to the Standard Library</em>, C++ committee document 
			N1436=03-0018, February 2003. Available online at <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1436.htm">
				http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1436.htm</a></p>
		<p>[<a name="Gregor03b">Gregor03b</a>] Douglas Gregor, <em>A Uniform Method for 
				Computing Function Object Return Types</em>, C++ committee document 
			N1437=03-0019, February 2003. Available online at <a href="http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1437.htm">
				http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1437.htm</a></p>
		<p>[<a name="Guzman02">Guzman02</a>] Joel de Guzman, <EM>Phoenix library documentation</EM>, 
			October 2002. Available online at <a href="http://spirit.sourceforge.net/index.php?doc=docs/phoenix_v1_0/index.html">
				http://spirit.sourceforge.net/index.php?doc=docs/phoenix_v1_0/index.html</a></p>
		<p>[<a name="Jarvi99">Järvi99</a>] Jaakko Järvi, <em>The Binder Library</em>, 
			September 1999. Available online at <a href="http://staff.cs.utu.fi/BL/">http://staff.cs.utu.fi/BL/</a></p>
		<p>[<a name="Jarvi00">Järvi00</a>] Jaakko Järvi, <em>C++ Function Object Binders Made 
				Easy</em>, Proceedings of the Generative and Component-Based Software 
			Engineering 99, Lecture Notes in Computer Science vol. 1977, August 2000. 
			Available online at <a href="http://osl.iu.edu/~jajarvi/publications/papers/function_object_binders_made_easy.ps">
				http://osl.iu.edu/~jajarvi/publications/papers/function_object_binders_made_easy.ps</a></p>
		<p>[<a name="Jarvi03">Järvi03</a>] Jaakko Järvi, Gary Powell, Andrew Lumsdaine, <em>The 
				Lambda Library: Unnamed Functions in C++</em>, Software: Practice and 
			Experience, vol. 33(3), pp. 259-291, March 2003.</p>
		<p>[<a name="Josuttis00">Josuttis00</a>] Nicolai Josuttis, <em>Compose Function Object 
				Adapters</em>, July 2000. Available online at <a href="http://www.boost.org/libs/compose/compose.html">
				http://www.boost.org/libs/compose/compose.html</a></p>
		<p>[<a name="Kempf02">Kempf02</a>] William E. Kempf, <i>The Boost.Threads Library</i>, 
			C/C++ Users Journal, May 2002. Available online at <a href="http://www.cuj.com/articles/2002/0205/0205a/0205a.htm?topic=articles">
				http://www.cuj.com/articles/2002/0205/0205a/0205a.htm?topic=articles</a></p>
		<p>[<a name="Rodgers00">Rodgers00</a>] Mark Rodgers, <em>Improved Function Object 
				Adaptors</em>, July 2000. Available online at <a href="http://www.boost.org/libs/functional/">
				http://www.boost.org/libs/functional/</a></p>
		<p>[<a name="SGI97a">SGI97a</a>] SGI STL documentation, <em>unary_compose</em>, 
			1997. Available online at <a href="http://www.sgi.com/tech/stl/unary_compose.html">http://www.sgi.com/tech/stl/unary_compose.html</a></p>
		<p>[<a name="SGI97b">SGI97b</a>] SGI STL documentation, <em>binary_compose</em>, 
			1997. Available online at <a href="http://www.sgi.com/tech/stl/binary_compose.html">
				http://www.sgi.com/tech/stl/binary_compose.html</a></p>
		<p>[<a name="Siek00">Siek00</a>] Jeremy Siek, <em>Transform Iterator Adaptor</em>, 
			2000. Available online at <a href="http://www.boost.org/libs/utility/transform_iterator.htm">
				http://www.boost.org/libs/utility/transform_iterator.htm</a></p>
		<p>[<a name="Simonis00">Simonis00</a>] Volker Simonis, <em>Adapters and Binders - 
				Overcoming Problems in the Design and Implementation of the C++-STL</em>, 
			February 2000. Available online at <a href="http://www.progdoc.de/papers/adapter_binder/adapter_binder/adapter_binder.html">
				http://www.progdoc.de/papers/adapter_binder/adapter_binder/adapter_binder.html</a></p>
		<p>[<a name="Stroustrup02">Stroustrup02</a>] Bjarne Stroustrup, <em>auto/typeof</em>, 
			C++ reflector message c++std-ext-5364, October 2002.</p>
		<p>[<a name="Williams01">Williams01</a>] Anthony Williams, <em>Flexible Functors and 
				Binders</em>, July 2001. Available online at <a href="http://web.onetel.net.uk/~anthony_w/cplusplus/functional.pdf">
				http://web.onetel.net.uk/~anthony_w/cplusplus/functional.pdf</a></p>
		<P>&nbsp;</P>
	</body>
</html>
