Notes for desired workflow for template instantiations in Drake
This is a stream-of-consciousness capture of the motivation behind this issue, per (VC) f2f with Jamie via scheduled meeting:
https://github.com/CastXML/CastXML/issues/171
From current state of autopybind11
(f60bae30), some observations:
- It looks like the emitted
wrapper.hpp
is used really to generate a manifest of instantiations and symbols for CastXML to produce info on. - For this reason, you have to concretely specify the type of each symbol (e.g.
functions
,classes
,named
, etc.)
The reason I'd like to avoid explicit enumeration is that one of the main pains of Drake is the explicit "dual" enumeration of public API (once in C++, again in pybind11
or via autopybind11
the config file).
Ideally, if the public API is easily parsable, there should be minimal (redundant) info necessary.
Allowing generic template parsing enables (a) explicit knowledge of the template relationships (and parameters, beyond string parsing), (b) minimal redundancy in things like docstrings, and (c) permits instantiations to be more easily structured (e.g. without needing CastXML
to see the instantiation, assuming there's no specialization).
Also, some additional design notes for Drake (that I dunno how to render into a more streamlined thought), where Drake has two "forms" of instantiations:
- Simple, "in-module" instantiations (e.g. templates on our standard scalar types). These fit the pattern of "use prescribed instantiations" (e.g. via parsed declared instantiations, parsing docstrings, some manifest, etc.)
- "cross-module" instantiations (e.g. our generic
Value[]
class, examples: 1, 2, 3)
The "in-module" instantiations I think are going to be easily accounted for. Dunno how to handle "cross-module" instantiations.
\cc @jamiesnape @brad.king @joe-snyder