There is an impedance mismatch between natural language concepts, Perl and C++. As mr_mischief as pointed out, it is centered in the representation of the concept 'number'.
Natural language concepts are vague and flexible. Like humpty dumpty, we make words mean whatever we choose them to mean. Numbers may be represented as spelled out words ('two' or 'tres'), various numeral systems ( '25' or 'XXV' ), they may be cardinal or ordinal.
Perl numbers are fluid and flexible. They may be internally represented as integers, floats or strings, or all of the above depending on how they are initialized and used. Most importantly there is a Perl concept of 'number' and it maps reasonably well onto the natural concept of cardinal numbers.
C++ has a group of concepts that together take the role of 'number'--there is no single concept of number. C and C++ operate on a lower level of abstraction. To simplify things, C and C++ define standard ways to automatically coerce (promote) specific types of number into other types as needed to perform common calculations. This creates an illusion of 'number'-ness. These allied concepts bear similarities to the natural concept, but fail to offer the flexibility we expect--you can promote a 16 bit integer into a 32 bit integer, but you can't do the converse. Your C++ library does not accept numbers, it accepts integers.
In theory, SWIG should be smart enough to handle the impedance mismatch and coerce or reject invalid input. That is what it is designed to do. It looks like the overloading on the method in your C++ library is confusing SWIG, since it sees two possible target methods. That you should have to fix the ambiguity for SWIG is not unreasonable. DWIMish systems may need help at times.
I don't know that I am narrow-minded when I write C or assembly, I try to always be mindful of what I am doing. That means that when I write C, I don't say to myself "this is a number", I say instead "this is an unsigned 16 bit integer". When I write 8051 assembly language, I say "this register contains the low order byte of an unsigned 16 bit integer". When I write Perl, I can safely say "this scalar contains a number" and only get more specific when the need arises.
In reply to Re: Revealing difference in interpretation of 'number' between Perl and $other_language