Omer Ozarslan created ARROW-6326:
------------------------------------
Summary: [C++] Nullable fields when converting std::tuple to Table
Key: ARROW-6326
URL: https://issues.apache.org/jira/browse/ARROW-6326
Project: Apache Arrow
Issue Type: New Feature
Components: C++
Reporter: Omer Ozarslan
{{std::optional}} isn't used for representing nullable fields in Arrow's
current STL conversion API since it requires C++17. Also there are other ways
to represent an optional field other than {{std::optional}} such as using
pointers or external implementations of optional ({{boost::optional}},
{{type_safe::optional}} and alike).
Since it is hard to maintain so many different kinds of specializations,
introducing an {{Optional}} concept covering these classes could solve this
issue and allow implementing nullable fields consistently.
So, the gist of proposed change will be something along the lines of:
{code:cpp}
template<typename T>
constexpr bool is_optional_like_v = ...;
template<typename Optional>
struct CTypeTraits<Optional, enable_if_t<is_optional_like_v<Optional>>> {
//...
}
template<typename Optional>
struct ConversionTraits<Optional, enable_if_t<is_optional_like_v<Optional>>> :
public CTypeTraits<Optional> {
//...
}
{code}
For a type {{T}} to be considered as an {{Optional}}:
1) It should be convertible (implicitly or explicitly) to {{bool}}, i.e. it
implements {{[explicit] operator bool()}},
2) It should be dereferencable, i.e. it implements {{operator*()}}.
These two requirements provide a generalized way of templating nullable fields
based on pointers, {{std::optional}}, {{boost::optional}} etc. However, it
would be better (necessary?) if this implementation should act as a default
while not breaking existing specializations of users (e.g. an existing
implementation in which {{std::optional}} is specialized by user).
Is there any issues this approach may cause that I may have missed?
I will open a draft PR for working on that meanwhile.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
