Menu
▾
▴
#964 Multi-argument typemaps without variable names do not work
I want to create a typemap for two sequential argument types but I don't want to specify the variable names. The documentation states that this should be possible, but multi-argument typemaps only seem to work when variable names are given:
-----------------------------
%module multi_test;
/*
// Does not work
%typemap(default) (int &, int &) {
// FOUND
}
*/
// Works
%typemap(default) (int &a, int &b) {
// FOUND
}
class Foobar {
public:
Foobar();
void test(int &a, int &b);
~Foobar();
};
-----------------------------
BTW, I saw this also reported at the following URL but did not find a bug submitted for it:
http://thread.gmane.org/gmane.comp.programming.swig/8527/focus=8536
I forgot to mention that I'm using SWIG 1.3.36.
Reproduced with current git master.
Interestingly
%typemap(default) (int &a, int &) {also works, but%typemap(default) (int &, int &b) {doesn't.I don't see where in the docs it explicitly says that omitting the parameter names should work though.
I do see this text (which has been there since before 2002 it seems):
That actually suggests to me that
%typemap(default) (int &, int &b) {would work but not%typemap(default) (int &a, int &) {(i.e. the opposite of the actual situation).The output with
-debug-tmsearchshows the typemaps don't match when they don't match, but doesn't help me understand why not.Last edit: Olly Betts 2024-10-22
Reproducible with SWIG 4.3.0.
Looking at the manual again, this part does actually seem to suggest that types without names should work:
@wsfulton Do you think this is a code bug or a documentation bug? I looked at the code and it makes my head spin, but I could fix the docs to clearly say this isn't supported (from my testing the first argument in a multi-argument typemaps currently needs to be named; for subsequent arguments names are optional).
It seems potentially useful if you want to apply a multi argument typemap but the naming of parameters in the API being wrapped isn't consistent across functions/methods (or the prototypes don't even have parameter names) and the parameter types are distinctive enough to not occur in the same order in cases you don't want to affect. However it does also seem fairly obscure.
I can imagine a pile of difficulties in the implementation and ambiguities in cases such as:
and multiple variations of the multi-arg typemaps in this ticket being present. If just the first name has to match, it is unambiguous as to whether or not the multi-argument typemap matches (once the subsequent parameters are checked).
I suppose some more flexible rules around such ambiguities could be defined and implemented, however, I would document it as it works currently and mention that currently there is a restriction that the first parameter must be named.
I would consider patches to address the restriction, but it might be a can of worms and is low priority.