bkietz opened a new issue, #38204:
URL: https://github.com/apache/arrow/issues/38204
### Describe the enhancement requested
We have a large number of type traits in `type_traits.h` which are used
inconsistently and whose relationships and specific semantics are not really
documented. These have been added ad-hoc as they were needed rather than
systematically laid out. I think instead of trying to construct them in
reflection the class hierarchy of `DataType` is only indirectly useful; what we
actually use these to check for is
- can I visit the slots of an array of this DataType?
- can those slots be represented as a `std::string_view` or are they numeric?
- does an array of this type have an offsets buffer, and if so what is its
type?
So I think it'd be more valuable to replace ambiguous traits like
`is_binary_like` and `is_string_like` altogether, perhaps with
`is_string_view_visitable` and `is_utf8`.
---
### Nice to haves:
At the same time, traits like `is_floating_type` could be upgraded to c++17
variable templates. These are partially specializable as with class templates,
so we wouldn't lose any flexibility by rewriting to:
```c++
namespace traits {
template <typename T>
constexpr bool is_floating_point = std::is_base_of_v<FloatingPointType, T>;
} // namespace traits
```
It'd also be nice to unify the template traits with the function traits
(which taking a `Type::type` or a `const DataType&` and return `bool`), so that
where one is available the other is definitely present (similar to the way
`enable_if` specializations are currently always present).
The `enable_if` specializations are handy but could be replaced by `if
constexpr` in many places.
### Component(s)
C++
--
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]
