On 10/05/2011 07:21 AM, Dave Abrahams wrote:
on Tue Sep 20 2011, "Niall Douglas" <s_sourceforge-AT-nedprod.com> wrote:
On 19 Sep 2011 at 17:03, Jim Bosch wrote:
I'd like to see support for static, template-based conversions. These would be defined by [partial-]specializing a traits class, and I tend to think they should only be invoked after attempting all registry-based conversions. Surely not! You'd want to let template specialisaton be the first point of call so the compiler can compile in obvious conversions, *then* and only then do you go to a runtime registry. I don't understand why you guys would want compile-time converters at all, really. Frankly, I think they should all be eliminated. They complicate the model Boost.Python needs to support and cause confusion when the built-in ones mask runtime conversions.
Indeed, I never understood that myself. At the Python/C++ language boundary there is no such thing as "compile-time".
This also lets one override the runtime registry when needed in the local compiland. I'm not against having another set of template specialisations do something should the first set of specialisations fail, and/or the runtime registry lookup fails. There are better ways to deal with conversion specialization, IMO. The runtime registry should be scoped, and it should be possible to find the "nearest eligible converter" based on the python module hierarchy.
...combined with some hints users can add to their modules. Again, I think we should favor explicit conversion policy settings over implicit ones. Sorry, I haven't yet managed to find time to sketch this out in any detail. I hope to be able to do that to help with this project, though. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...