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.

[Vipul-Cariappa]

Just a note about the double/float comments.
double and float are not accepted as non-type template parameters.
Only integers and integer-like (enums) are allowed.
https://godbolt.org/z/71e4Tzevh

[wlav]

Okay, but then I'd make the same comment about 3 and 3u.

[vgvassilev]

LGTM if the bots are happy.

[Vipul-Cariappa]

@vgvassilev, I have pushed a comment linking to the comment you have made on supporting template instantiation using string. If you think that is sufficient, then we can merge this. Will enable 5 tests.

[vgvassilev]

@vgvassilev, I have pushed a comment linking to the comment you have made on supporting template instantiation using string. If you think that is sufficient, then we can merge this. Will enable 5 tests.

Are we going to ignore the bots?

[Vipul-Cariappa]

Hi @vgvassilev, I will go ahead and merge in PR in few minutes. The failures in cling need the tags to be update to not run the tests. I.e. previous xfails are now crashing in cling.