Not ArrayView yet, and also no documentation on this whatsoever. That'll
come next. Also not everything works with arbitrary types yet,
converting from buffer protocol doesn't remember the format and
conversion to bytes doesn't take the actual type size into account
either.
Compared to having to subclass every type that can reference external
data, this has several advantages for 3rd party binding code:
* it doesn't need to worry about the additional type when binding
function arguments (currently it had to provide lambdas that accept
the PyFoo subtype instead of just Foo)
* and it can now easily bind those types also for function
return values and properties -- the return type doesn't need to be
subclassed (which in case of move-only types is practically
impossible) but instead just wrapped in a holder along with the
memory owner object reference
The new holders also assert that memory owner is always specified unless
the data is empty.
That makes it much easier to handle in that case (because that's the
whole point of static builds) and also nicely circumvents any issues
with duplicated global data when a static lib would be linked to
multiple dynamic libraries.
Only the double ones, exposed as floats, because the extra ALU required
by doubles is negligible to function call overhead. It'll be different
for non-scalar types, but here I use this.
Vladimír Vondruš