support template instantiation using integral values

[Vipul-Cariappa]

Hi @vgvassilev, the string parsing is required here. Because cppyy allows instantiation using strings. For example:

In [1]: import cppyy

In [2]: from cppyy import gbl

In [3]: cppyy.cppdef("""
   ...: template<typename T, int N>
   ...: T add(T n) { return n + (T)N; }
   ...: """)
Out[3]: True

In [4]: gbl.add[int, 5](5)
Out[4]: 10

In [5]: gbl.add["int", "6"](5)
Out[5]: 11

In [6]: gbl.add["int, 7"](5)
Out[6]: 12

Enables 5 tests:

test_stltypes.py::TestSTLTUPLE::test01_tuple_creation_and_access
test_stltypes.py::TestSTLTUPLE::test03_tuple_iter
test_stltypes.py::TestSTLTUPLE::test04_tuple_lifeline
test_templates.py::TestTEMPLATES::test02_non_type_template_args
test_templates.py::TestTEMPLATES::test03_templated_function

[vgvassilev]

You probably need a clang::Lexer here.

[aaronj0]

Leaking clang::Lexer into clingwrapper? I believe that should be abstracted into CppInterOp...

[vgvassilev]

I realize that is going to be an overkill and yes, @aaronj0 is right -- we can't really do it. The question is if we want to support that case? Especially the comma separated argument list in a form of string...

[vgvassilev]

I am really not seeing if In [6]: gbl.add["int, 7"](5) is something useful and worth supporting. In cppyy upstream it was easy to implement but it is really worth implementing it. cc: @wlav.

[wlav]

It's a legitimate use, but an unlikely one b/c both "int" and "7" are valid Python objects, so no quotes needed. I.e., writing "int, 7" is more work than writing int, 7 and thus unlikely. I would also assume that in practice the integer is programmatically established, in which case again it's be a number and not a string.

I don't have a test case that looks like this, which may mean no-one ever asked for it, but that may also be b/c it simply worked.

The only case I may see a use, is if the literal is typed. So e.g. if the templated function is overloaded with the second argument being either C++ double or C++ float and it is expected that the literal is either 3.14 or 3.14f or some such. You can't do that in python: it'd have to be a string. (A workaround could be to use a numpy.float32.)

All that said, see it as a challenge. :)

[vgvassilev]

But in that case we will pass it as “3.14f” instead of “something, something, 3.14f”. The former is way simpler to support than the latter.

[vgvassilev]

Let's move forward with the proposed approach. Can we add a fixme capturing the debate whether we want to support that feature.