diff options
author | Olly Betts <olly@survex.com> | 2022-07-11 15:37:53 +1200 |
---|---|---|
committer | Olly Betts <olly@survex.com> | 2022-07-11 16:39:14 +1200 |
commit | 63c681a5139050b0e44fd9a7cf79bd5eee538916 (patch) | |
tree | dfb632ce9f8ea9fe183b9c08afbf90719e827b19 /TODO | |
parent | cf9422b4d985faee722643c8b8ccda954d10063e (diff) | |
download | swig-63c681a5139050b0e44fd9a7cf79bd5eee538916.tar.gz |
TODO: Remove nested typemaps since now supported
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 74 |
1 files changed, 0 insertions, 74 deletions
@@ -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. |