TODO: Remove nested typemaps since now supported

TODO

@@ -26,80 +26,6 @@ defer  ready to go.  The primary obstacle lies in the target language
        This is one of the last remaining "hard" problems in the SWIG
        core, but it is important that we solve it.
 
-***    "Nested" typemaps. The basic idea is similar to allowing one to 
-       use $descriptor(T) for any T, rather than just $descriptor
-       for the type currently being typemapped.
-
-       In short (ha!), given a previously defined typemap:
-
-       %typemap(in) Foo {
-           // whatever it takes to initialize $1 from $input
-       }
-
-       it would be possible to inline its code inside another typemap. 
-       While the syntax is still to be defined, the use would be
-       along the lines of:
-
-       template <class T> class vector {
-           %typemap(in) vector<T> {
-               ...
-               for (int i=0; i<N; i++) {
-                   PyObject* x = ... // i-th element
-                   $typemap(in, T, x, $1[i]);
-               }
-               ...
-           }
-           ...
-       }
-
-       i.e., when $typemap(in,Foo,x,y) is encountered, it will
-       be replaced by the code for %typemap(in) Foo; in the latter,
-       x will be replaced for $input and y will be replaced for $1. 
-       As in the case above, x and y themselves might need to be 
-       expanded before or after being substituted in the typemap code.
-       Also, $typemap(what,Foo,x,y,z,...) will be used in case of 
-       multi-arguments typemaps. The same will hold for "out" typemaps
-       and all the others.
-
-       Comment by mkoeppe:  
-
-	  I think we need to be careful to keep the syntax readable.
-	  I would like to get a syntax that is close to that of
-	  typemap definitions.  So consider this typemap:
-
-		 %typemap(in) int { ... }
-
-	  I would like to refer to this typemap like this:
-
-		 $typemap(in, input=x) int = foo;
-
-	  Here $input would be replaced by the given keyword argument
-	  x, and $1 would be replaced by foo.
-
-	  This syntax would extend easily to multi-typemaps:
-
-		 %typemap(in) ( int FIRST, double SECOND ) { ... }
-
-	      -> $typemap(in, input=x) 
-	      	    ( int FIRST = foo, double SECOND = bar );
-
-	  The advantage of this syntax would be that the formal
-	  arguments (int FIRST, double SECOND) are close to the
-	  actual arguments (foo, bar).
-
-	Comment by beazley
-
-               $typemap(in, input=x) int = foo;
-
-        is a little bit hard to parse in terms of variable substitution.
-        I'm considering something like this:
-
-               $typemap(in,1=int foo, input=x)
-
-       Note: This is partially implemented in the new Unified Typemap
-       Library(python,tcl,ruby and perl) via %fragments and the
-       SWIG_From/SWIG_AsVal methdos.
-
 ***    Implement $fail special variable substitution in wrappers. Used
        to properly transfer control out of a wrapper function while
        reclaiming resources.