It’s a bit painful but the asPEEK debugging code shows more of the nitty-gritty of accessing Angelscript objects C++ side. Can’t for the life of me remember how much array handling there was … I do recall it and remembering it sucked.
If I give up on template specialization at runtime, and restrict myself to VariantVector, it looks like I’ll be able to handle angelscript array runtime specialization with what little type information I have.
That’s probably the smarter choice. Restricting to VariantVector / StringVector / ResourceRefList returns implies a lot in regards to constraints and reduces how robust you might have to be.
If a returned CScriptArray contains exclusively angelscript defined types then any C++ code attempting to store them will have to bump/dec the reference counts for those objects. Obviously you don’t look to be after going that far, but using the generic type looks like you could be.
VariantVector (and kin) makes it a lot clearer … provided Variant
VoidPtr isn’t supported for Angelscript objects, but that isn’t that bad as it would still be clear that ref-counts are the end-user’s responsibility.
I’m warning you of those points specifically because of your BehaviorTree thread - from my own experience with a C++ side BT-core that supported tree-nodes defined in angelscript.
I’ve done this before, from what I saw in the other thread you’re on the right track. There is no getting this truly right, so pick a point and settle on it.