Answer the eternal operator== question.

[SVN r20356]

doc/faq.xml

@@ -5,6 +5,87 @@
   <title>Frequently Asked Questions</title>
 
 <qandaset>
+  <qandaentry>
+    <question><para>Why can't I compare
+    <classname>boost::function</classname> objects with
+    <code>operator==</code> or
+    <code>operator!=</code>?</para></question>
+
+    <answer>
+      <para>Comparison between <classname>boost::function</classname>
+      objects cannot be implemented "well", and therefore will not be
+      implemented. The typical semantics requested for <code>f ==
+      g</code> given <classname>boost::function</classname> objects
+      <code>f</code> and <code>g</code> are:</para>
+        <itemizedlist>
+          <listitem><simpara>If <code>f</code> and <code>g</code>
+          store function objects of the same type, use that type's
+          <code>operator==</code> to compare
+          them.</simpara></listitem> 
+
+          <listitem><simpara>If <code>f</code> and <code>g</code>
+          store function objects of different types, return
+          <code>false</code>.</simpara></listitem>
+        </itemizedlist>
+      <para>The problem occurs when the type of the function objects
+      stored by both <code>f</code> and <code>g</code> doesn't have an
+      <code>operator==</code>: we would like the expression <code>f ==
+      g</code> to fail to compile, as occurs with, e.g., the standard
+      containers. However, this is not implementable for
+      <classname>boost::function</classname> because it necessarily
+      "erases" some type information after it has been assigned a
+      function object, so it cannot try to call
+      <code>operator==</code> later: it must either find a way to call
+      <code>operator==</code> now, or it will never be able to call it
+      later. Note, for instance, what happens if you try to put a
+      <code>float</code> value into a
+      <classname>boost::function</classname> object: you will get an
+      error at the assignment operator or constructor, not in
+      <code>operator()</code>, because the function-call expression
+      must be bound in the constructor or assignment operator.</para>
+
+      <para>The most promising approach is to find a method of
+      determining if <code>operator==</code> can be called for a
+      particular type, and then supporting it only when it is
+      available; in other situations, an exception would be
+      thrown. However, to date there is no known way to detect if an
+      arbitrary operator expression <code>f == g</code> is suitably
+      defined. The best solution known has the following undesirable
+      qualities:</para>
+
+      <orderedlist>
+        <listitem><simpara>Fails at compile-time for objects where
+        <code>operator==</code> is not accessible (e.g., because it is
+        <code>private</code>).</simpara></listitem>
+
+        <listitem><simpara>Fails at compile-time if calling
+        <code>operator==</code> is ambiguous.</simpara></listitem>
+
+        <listitem><simpara>Appears to be correct if the
+        <code>operator==</code> declaration is correct, even though
+        <code>operator==</code> may not compile.</simpara></listitem>
+      </orderedlist>
+
+      <para>All of these problems translate into failures in the
+      <classname>boost::function</classname> constructors or
+      assignment operator, <emphasis>even if the user never invokes
+      operator==</emphasis>. We can't do that to users.</para>
+
+      <para>The other option is to place the burden on users that want
+      to use <code>operator==</code>, e.g., by providing an
+      <code>is_equality_comparable</code> trait they may
+      specialize. This is a workable solution, but is dangerous in
+      practice, because forgetting to specialize the trait will result
+      in unexpected exceptions being thrown from
+      <classname>boost::function</classname>'s
+      <code>operator==</code>. This essentially negates the usefulness
+      of <code>operator==</code> in the context in which it is most
+      desired: multitarget callbacks. The
+      <libraryname>Signals</libraryname> library has a way around
+      this.</para>
+    </answer>
+  </qandaentry>
+
   <qandaentry>
     <question><para>I see void pointers; is this [mess] type safe?</para></question>
     <answer>