Hoisting this from:
https://github.com/RobotLocomotion/drake/issues/11648#issuecomment-632700236
Basically, there's a crap tonne of weird pybind11 magic that can't be encapsulated in a function call; e.g. PYBIND11_MAKE_OPAQUE, as shown in @mntan3's awesome PR:
https://github.com/RobotLocomotion/drake/pull/13359/files
Rather than requiring that Value<std::vector<T>> be bound opaquely for every type of std::vector<T>, instead, I should generate a new Python object that can easily associate with typeinfo(std::vector<T>), e.g. something like List[T].
Relates discussion here:
https://github.com/robotlocomotion/drake/pull/13364#issuecomment-632771660
cc @amcastro-tri
Working on this now, should have solution shortly.
Solution posted: #13407
BTW This issue seems to serve for you as a work-tracking ticket. However, it provides very little insight for future developers. Could you extend the original comment to describe the "hurt" as that may better enable other developers to better contribute in this regard. Otherwise, it's all trapped inside your mind.
To second Sean's comment, I am worried by this and #13398 that the straightforward abstraction represented by AbstractValue is being compromised unnecessarily. I understand that we may need to restrict our use of that abstraction in some cases to avoid trouble with pybinding, but that should not affect a user who is working only in C++ and might want to make ports or cache entries containing types that wouldn't pybind nicely.
As shown by the above-linked PR #13407, there is a solution that still permits type-erasing std::vector<> by adjusting how the pybind adaptation is formulated. The plan is not to exclude std::vector<> as a port or cache entry type.
Reworded to focus on bindings, not Value<>.