-
Notifications
You must be signed in to change notification settings - Fork 223
Add array::downcast_ref
and array::downcast_mut
#1566
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #1566 +/- ##
==========================================
- Coverage 83.06% 83.05% -0.01%
==========================================
Files 391 391
Lines 42889 42930 +41
==========================================
+ Hits 35626 35657 +31
- Misses 7263 7273 +10
☔ View full report in Codecov by Sentry. |
4daf21c
to
82e6cae
Compare
82e6cae
to
ed0fb30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about this. You can say something like this for any Option
returning method. To me this feels something that needs to be resolved by the consumer of the arrow2 crate.
It's your call, but in my recent experiences as a daily arrow2 user, when you're dealing when reading lots of box-arrays from various sources (e.g. dealing with struct-like data and the like), it's downcasts all over the place. If you want to avoid unwraps, you will have to The core difference between "just let the user figure it out, it's an option" here is that the array itself (both A minor side effect here is that it unifies downcasting of both array/mutable-array, but that's not the most important part. |
This introduces
array::downcast_ref()
andarray::downcast_mut()
helpers, providing a nicer downcasting interface which makes use of errors, so you could e.g. (in a result-context)Downstream, if you're using arrow2, chances are you're converting
arrow2::error::Error
into your errors already anyway somewhere along the line, and working withResult
is nicer thenOption
most of the time, because otherwise you'll have to.ok_or_else()
on every downcast call.