Alright in light of this I'll rewrite that PR to a traits based approach.
Thanks all
On Fri, Jul 23, 2021 at 9:12 AM Wes McKinney wrote:
> Like Antoine, I am not sure how comfortable I am with this the way it
> is now. On one hand I see the benefits in the reduction of
> boilerplate. On the othe
Like Antoine, I am not sure how comfortable I am with this the way it
is now. On one hand I see the benefits in the reduction of
boilerplate. On the other, making the code more "magical" through meta
constructs likely makes it less accessible to contributors. It also
makes it so that IDEs (Clion, V
It feels like not using regular enums would be optimizing more for the
producers of the library than the users that will be consuming it. It
could definitely reduce the burden of writing some boiler plate code but
this means that everyone that wants to use Arrow has another concept they
have to le
As I said on the PR, I'm worried that it will raise eyebrows or even
make people defiant about using our C++ APIs. Basically, users of a
language are accustomed to certain idioms and often wary of software
packages that redefine their own variants of core language
functionality. Even I fin
I support having a C++ meta enum construct as it will provide functionalities
not readily allowed with standard enums. For example, I have found scenarios
(mainly for writing tests) where iterating through the enum values would be
useful.
Is the rationale of this proposal to replace all C++ enu
