-
Notifications
You must be signed in to change notification settings - Fork 224
Conversation
Codecov Report
@@ Coverage Diff @@
## main #607 +/- ##
==========================================
+ Coverage 69.70% 69.93% +0.22%
==========================================
Files 299 300 +1
Lines 16599 16835 +236
==========================================
+ Hits 11571 11773 +202
- Misses 5028 5062 +34
Continue to review full report at Codecov.
|
78c1770
to
34e0eba
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.
LGTM, but if you can use expect to prompt the user that the type does not match, it will be better than unwrap directly
@yjhmelody , thanks! Could you clarify what do you mean with
So, the design here is: the statically-typed versions of the operators do not check for the type; the dynamically-typed versions of the operators check for type. I am uncertain about this choice, though: my hypothesis here:
thus, they can match for a valid datatype via if can_add(array1.data_type(), array2.data_type()) {
Ok(add(array1, array2))
} else {
// custom add for arrow2-unsupported type or error
} Could you clarify your thoughts on this? Also @houqp @ritchie46 @sundy-li |
I agree with you. I just suggest not to use the |
34e0eba
to
800b1f7
Compare
iirc unwrapping a Result and will show the result's error message on the panic. |
Closes #527.
The functions are now offered based on the name instead of
Operator
(which was removed).Also, the functions no longer error, and instead panic. As usual,
can_*
can be used to check if the operation is supported, and checking thelen
of the arrays is required.