[
https://issues.apache.org/jira/browse/ARROW-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ARROW-6326:
----------------------------------
Labels: pull-request-available (was: )
> [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
> Priority: Major
> Labels: pull-request-available
>
> {{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)
