At the moment we don’t ever make use of nullable components.
For instance: we don’t allow setting the radius of only some points in a point-cloud to null.
Still, we have full support for it in our Loggable trait and in our codegen.
We have a to_arrow_opt taking an iterator of optional values, and a from_arrow_opt that returns a Vec<Option<Self>>, yet these are never called.
This unused support has several downsides:
- Extra complexity in the codegen
- A lot of extra generated code (we generate both
from_arrow_opt and from_arrow)
- Runtime overhead (we codegen
to_arrow_opt, but only ever call to_arrow which wraps each element in Some(…))
Removing support for it would definitely make the transition away from arrow2 easier. And we can always add it back in the future.
It seems silly to support a feature we may want in the future (YAGNI / ease into complexity).
At the moment we don’t ever make use of nullable components.
For instance: we don’t allow setting the radius of only some points in a point-cloud to
null.Still, we have full support for it in our
Loggabletrait and in our codegen.We have a
to_arrow_opttaking an iterator of optional values, and afrom_arrow_optthat returns aVec<Option<Self>>, yet these are never called.This unused support has several downsides:
from_arrow_optandfrom_arrow)to_arrow_opt, but only ever callto_arrowwhich wraps each element inSome(…))Removing support for it would definitely make the transition away from
arrow2easier. And we can always add it back in the future.It seems silly to support a feature we may want in the future (YAGNI / ease into complexity).