Relevant to this thread: https://github.com/apache/arrow/pull/10691
adds an enum replacement which includes compile-time to/from strings.
This should reduce repetitive boilerplate in the bindings and elsewhere
mapping to/from user provided string values.
On Mon, Jun 14, 2021 at 11:17 PM Micah Korn
>
> In light of this my preference would be: public enums must be scoped and
> named in CamelCase. The style guide would require kCamelCase but it does so
> for consistency with public _unscoped_ enums. IMO we'd be better served by
> requiring scoped enums, which obviates the 'k' prefix.
This see
My two cents:
kSomeConstant includes the prefix 'k' so that regardless of what expression
it appears in, it is unambiguously a global constant. I'm restating the
obvious here to clarify that the goal is making names obviously global.
Note that a prefix is redundant for any qualified name (appears
The style guide doesn't make a distinction [1] between scoped and
unscoped. Ultimately, I'm happy to go with whatever the consensus is but
one of the reasons for adopting a style guide is to limit discussions like
this when there are multiple reasonable paths forward.
[1] https://google.github.io
We're talking about new enums here, which should always be scoped enums,
i.e.:
enum class MyEnum { };
Le 04/06/2021 à 21:41, Wes McKinney a écrit :
I think we should use the kCapWords naming scheme for global
const/constexpr values and for bare (non-scoped) enum values. For
example:
enu
I think we should use the kCapWords naming scheme for global
const/constexpr values and for bare (non-scoped) enum values. For
example:
enum MyEnum {
kMyEnum_Value1,
kMyEnum_Value2,
};
but not
struct MyEnum {
enum type {
...
};
};
Does that seem like a reasonable distinction? I thin
I would prefer kCamelCaps to be inline with the style guide (unless we are
too far down a different path).
On Fri, Jun 4, 2021 at 12:37 PM Antoine Pitrou wrote:
>
> Le 04/06/2021 à 21:34, Weston Pace a écrit :
> > The C++ code base currently has a mix of ALL_CAPS (e.g.
> > arrow::ValueDescr::Sha
Le 04/06/2021 à 21:34, Weston Pace a écrit :
The C++ code base currently has a mix of ALL_CAPS (e.g.
arrow::ValueDescr::Shape, seems to be favored in arrow::compute::),
CapWords (e.g. arrow::StatusCode), and kCapWords (e.g.
arrow::DecimalStatus, not common in arrow:: but used in gandiva:: and
t
The C++ code base currently has a mix of ALL_CAPS (e.g.
arrow::ValueDescr::Shape, seems to be favored in arrow::compute::),
CapWords (e.g. arrow::StatusCode), and kCapWords (e.g.
arrow::DecimalStatus, not common in arrow:: but used in gandiva:: and
technically what the Google style guide recommends
