jhorstmann opened a new issue, #1948:
URL: https://github.com/apache/arrow-rs/issues/1948

   **Is your feature request related to a problem or challenge? Please describe 
what you are trying to do.**
   
   Many Array types have a `value` and `value_unchecked` method. This method is 
not part of the `Array` trait because the return type would need to be a 
generic parameter, which would make the `Array` trait no longer object safe.
   
   The absence of such a method makes it more difficult to abstract over 
different array types. For example the [iterators have a lot of code 
duplication](https://github.com/apache/arrow-rs/blob/9f7b6004d365b0c0bac8e30170b49bdd66cc7df0/arrow/src/array/iterator.rs#L135)
 or the [comparison functions use macros as a 
workaround](https://github.com/apache/arrow-rs/blob/9f7b6004d365b0c0bac8e30170b49bdd66cc7df0/arrow/src/compute/kernels/comparison.rs#L60).
   
   **Describe the solution you'd like**
   
   I propose to add another trait (maybe named `ArrayAccessor`) that would 
unify the types:
   
   ```rust
   trait ArrayAccessor: Array {
       type Item;
       fn value(&self, index: usize) -> Self::Item;
       unsafe fn value_unchecked(&self, index: usize) -> Self::Item;
   }
   ```
   
   This could be implemented by `PrimitiveArray`, `BooleanArray`, 
`StringArray`, `BinaryArray, `ListArray` and maybe more.
   
   An interesting case is `DictionaryArray` where we might want two different 
accessors, one for keys and another that resolves keys to their corresponding 
values (haven't checked whether this would be possible to implement in a 
generic way).
   
   Iterators and comparison kernels could then be implement in a generic way 
using this trait, reducing the amount of macros in the code base.
   
   **Describe alternatives you've considered**
   
   We could keep using macros.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to