[blink-dev] C++ Feature Proposal: allow "enum class"

Post by Mounir Lamouri
Allow enum to be marked as classes.
Being able to forward declare enums which can be very good for public
interfaces and generally speaking reduces headers inclusions.
This is not about specifying a type on an enum for which I have no
opinion and no strong use cases.
http://en.cppreference.com/w/cpp/language/enum
-- Mounir
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

We frequently and regularly serialize enums. Are there any implications for
how this serialization would work? (I don't think they are, but the
subtlety of the type may affect some of our template magic).

Otherwise, I like every excuse to forward declare ALL the things!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Daniel Cheng

2014-09-24 16:20:55 UTC

The implicit integral conversion no longer works with strongly-typed enum,
but you can still static_cast them. Of course, to do so correctly, one
would probably want to use std::underlying_type in <type_traits> which is a
library feature...

Daniel

Post by Ryan Sleevi

We frequently and regularly serialize enums. Are there any implications
for how this serialization would work? (I don't think they are, but the
subtlety of the type may affect some of our template magic).
Otherwise, I like every excuse to forward declare ALL the things!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Elliott Sprehn

2014-09-24 16:24:40 UTC

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed enum,
but you can still static_cast them. Of course, to do so correctly, one
would probably want to use std::underlying_type in <type_traits> which is a
library feature...

Sounds like this is going to make piping together a series of flags a lot
less readable?

- E

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Alex Vakulenko

2014-09-24 16:26:24 UTC

Then maybe flags shouldn't be an enum after all.

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a lot
less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Anton Staaf

2014-09-24 17:01:50 UTC

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class, but
their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.

-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a lot
less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

James Cook

2014-09-24 17:15:36 UTC

+1. I frequently hit forward-declaration problems in UI code due to enums.

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class,
but their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.
-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a
lot less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
To unsubscribe from this group and stop receiving emails from it, send an

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

'Alex Vakulenko' via blink-dev

2014-09-24 17:25:38 UTC

Anton,

I think you are onto something here. We can start with a simple class like
this:

template<class EnumType>class FlagSet { public:
using UnderlyingType = typename std::underlying_type<EnumType>::type;

FlagSet(const std::initializer_list<EnumType>& set)
: value_(std::accumulate(set.begin(), set.end(), 0, BitOr)) {
}
UnderlyingType GetValue() const { return value_; }
bool HasFlag(EnumType flag) const { return (value_ & Cast(flag)) != 0; }
private:
static UnderlyingType BitOr(UnderlyingType acc, EnumType val) {
return acc | Cast(val);
}
static inline UnderlyingType Cast(EnumType val) {
return static_cast<UnderlyingType>(val);
}
UnderlyingType value_;};

Then you can do something like this:

enum class MyFlag {
foo = 1,
bar = 2,
baz = 4};
bool HasFoo(FlagSet<MyFlag> flags) {
return flags.HasFlag(MyFlag::foo);}
int main() {
bool has_foo = HasFoo({MyFlag::foo, MyFlag::bar});
return 0;}

This is very simple, of course and uses initializer_list. It has a problem
that the enum values must be a bit values. Having something like your
EnumSet where you can have any set of enums (irrespective of their values)
is a step forward, but will be a problem with interfacing with library code
that expects real bit field integers...

Alex

Post by James Cook
+1. I frequently hit forward-declaration problems in UI code due to enums.

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class,
but their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.
-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a
lot less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev
To unsubscribe from this group and stop receiving emails from it, send an

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Alex Vakulenko

2014-09-24 17:26:55 UTC

Now from the correct account...

Anton,

Post by 'Alex Vakulenko' via blink-dev
I think you are onto something here. We can start with a simple class like
using UnderlyingType = typename std::underlying_type<EnumType>::type;
FlagSet(const std::initializer_list<EnumType>& set)
: value_(std::accumulate(set.begin(), set.end(), 0, BitOr)) {
}
UnderlyingType GetValue() const { return value_; }
bool HasFlag(EnumType flag) const { return (value_ & Cast(flag)) != 0; }
static UnderlyingType BitOr(UnderlyingType acc, EnumType val) {
return acc | Cast(val);
}
static inline UnderlyingType Cast(EnumType val) {
return static_cast<UnderlyingType>(val);
}
UnderlyingType value_;};
enum class MyFlag {
foo = 1,
bar = 2,
baz = 4};
bool HasFoo(FlagSet<MyFlag> flags) {
return flags.HasFlag(MyFlag::foo);}
int main() {
bool has_foo = HasFoo({MyFlag::foo, MyFlag::bar});
return 0;}
This is very simple, of course and uses initializer_list. It has a problem
that the enum values must be a bit values. Having something like your
EnumSet where you can have any set of enums (irrespective of their values)
is a step forward, but will be a problem with interfacing with library code
that expects real bit field integers...
Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

James Robinson

2014-09-24 17:43:27 UTC

This proposal is off-topic since it uses initializer_list, which we don't
have.

Could somebody please post an example of real code in chromium with and
without this proposal?

- James
â

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Elliott Sprehn

2014-09-24 17:24:58 UTC

That seems like a large amount of complexity to replace what bit operators
do. It also uses more memory and is slower. Blink needs something that's as
fast as or'ing ints together (same number of ASM instructions).

We also can't omit type names, they're important documentation.

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class,
but their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.
-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a
lot less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Victor Khimenko

2014-09-24 17:32:09 UTC

Post by Elliott Sprehn
That seems like a large amount of complexity to replace what bit operators
do. It also uses more memory and is slower. Blink needs something that's as
fast as or'ing ints together (same number of ASM instructions).
We also can't omit type names, they're important documentation.
What kind of documentation value could they offer? When you combine two

elements of enum the result is not element of enum, it's int (or long, or
char - depending on the underlaying type of enum).

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class,
but their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.
-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a
lot less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Anton Staaf

2014-09-24 17:32:15 UTC

Last time I checked the assembly output from this template under GCC (4.8.2
0O3) it does just fold down to an int that gets or'ed or and'ed together.
So I'm not sure what extra memory and slowness you see, please enlighten
me. Also, what type names are missing?

Thanks,
Anton

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class,
but their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.
-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a
lot less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Stephen Chenney

2014-09-25 15:41:22 UTC

It helps to understand that enums are used extensively in Blink in an
effort to make code more readable in the absence of any comments. I believe
that is what Elliott is talking about. In that case the type name of the
enum is supposed to tell you what it means when you see it in a method
signature or the like. If you drop the enum name for things that are
logically flags then you lose this self-documentation feature, particularly
when the style checker frequently forces you to drop the names of arguments
in headers (although I have not reverse engineered the exact circumstances
in which it does so).

So we end up with:

void someMethod(MethodStateFlags);

rather than

void someMethod(int);

because the checker will complain about

void someMethod(int stateFlags);

pkasting@'s forked thread suggests using constants for bitfield contents to
address this particular problem, which I personally prefer, but I believe
we would have to move to that piecemeal.

Stephen.

Post by Anton Staaf
Last time I checked the assembly output from this template under GCC
(4.8.2 0O3) it does just fold down to an int that gets or'ed or and'ed
together. So I'm not sure what extra memory and slowness you see, please
enlighten me. Also, what type names are missing?
Thanks,
Anton

Post by Elliott Sprehn
That seems like a large amount of complexity to replace what bit
operators do. It also uses more memory and is slower. Blink needs something
that's as fast as or'ing ints together (same number of ASM instructions).
We also can't omit type names, they're important documentation.

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

I would argue that the flags should be represented using an enum class,
but their combinations should be a different type. I wrote a C++11 EnumSet
that is a class templatized by an enum class that supports most of what you
would expect from a set and stores the set in a densely packed integer
array. The result is quite pleasing, though there are some rough edges.
In particular, without reflection you have to annotate the enum class with
a count or last element so that the template knows how bit the int array
should be. I've attached the implementation and unit tests for example
uses. I was half way through converting it to all constexpr operations
when I last worked on this, so there are some constexpr warts.
-Anton

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...

Sounds like this is going to make piping together a series of flags a
lot less readable?
- E
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Kevin Schoedel

2014-10-01 19:12:51 UTC

Leaving aside any questions of what to do about existing or future
*unscoped* enums (Google Style Guide is silent, last I looked), are there
objections to using scoped enums (enum class) where appropriate?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Victor Khimenko

2014-10-01 19:50:03 UTC

Post by Kevin Schoedel
Leaving aside any questions of what to do about existing or future
*unscoped* enums (Google Style Guide is silent, last I looked), are there
objections to using scoped enums (enum class) where appropriate?
It's in the list of "C++11 Features To Be Discussed", sadly. Because "I

think we have reached enough allowed things for one week".

That was one week ago, perhaps we could add something else to said list of
things? "enum class", e.g.?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Stuart Morgan

2014-10-01 20:58:16 UTC

Is it worth considering a requirement to use kEnumStyle for class enums
(if/when they are approved), instead of OLD_ENUM_STYLE, so that as enums
are modernized for C++11 we'll also be eliminating a legacy divergence from
Google style?

Obviously this is tangential to actually allowing them, but if we deicide
up front we could use this opportunity to modernize our enum style,
especially since the namespacing will likely mean all the value names would
change anyway (since they won't need long common prefixes to stand in for
namespaces).

-Stuart

Post by Victor Khimenko

Post by Kevin Schoedel
Leaving aside any questions of what to do about existing or future
*unscoped* enums (Google Style Guide is silent, last I looked), are
there objections to using scoped enums (enum class) where appropriate?
It's in the list of "C++11 Features To Be Discussed", sadly. Because "I

think we have reached enough allowed things for one week".
That was one week ago, perhaps we could add something else to said list of
things? "enum class", e.g.?
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Victor Khimenko

2014-10-01 21:46:20 UTC

Post by Stuart Morgan
Is it worth considering a requirement to use kEnumStyle for class enums
(if/when they are approved), instead of OLD_ENUM_STYLE, so that as enums
are modernized for C++11 we'll also be eliminating a legacy divergence from
Google style?
Obviously this is tangential to actually allowing them, but if we deicide
up front we could use this opportunity to modernize our enum style,
especially since the namespacing will likely mean all the value names would
change anyway (since they won't need long common prefixes to stand in for
namespaces).
But why would they need that "k" prefix then? Style of enum elements for

class enums is interesting question: Google3 left "k" there "by historical
reasons" (it's no longer needed to distinguish enum members from all other
identifiers), but is it wise to use it in Chromium codebase if we've never
actually used it?

Post by Stuart Morgan
-Stuart

Post by Victor Khimenko

Post by Kevin Schoedel
Leaving aside any questions of what to do about existing or future
*unscoped* enums (Google Style Guide is silent, last I looked), are
there objections to using scoped enums (enum class) where appropriate?
It's in the list of "C++11 Features To Be Discussed", sadly. Because "I

think we have reached enough allowed things for one week".
That was one week ago, perhaps we could add something else to said list
of things? "enum class", e.g.?
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Brett Wilson

2014-10-01 22:00:14 UTC

Post by Stuart Morgan

Post by Stuart Morgan
Is it worth considering a requirement to use kEnumStyle for class enums
(if/when they are approved), instead of OLD_ENUM_STYLE, so that as enums are
modernized for C++11 we'll also be eliminating a legacy divergence from
Google style?
Obviously this is tangential to actually allowing them, but if we deicide
up front we could use this opportunity to modernize our enum style,
especially since the namespacing will likely mean all the value names would
change anyway (since they won't need long common prefixes to stand in for
namespaces).

But why would they need that "k" prefix then? Style of enum elements for
class enums is interesting question: Google3 left "k" there "by historical
reasons" (it's no longer needed to distinguish enum members from all other
identifiers), but is it wise to use it in Chromium codebase if we've never
actually used it?

It's named like a constant ("kFoo"), which seems like a good idea. I
do not think Chrome should diverge from Google style in this respect.

Brett

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

'Peter Kasting' via blink-dev

2014-09-24 22:46:32 UTC

Post by Alex Vakulenko
Then maybe flags shouldn't be an enum after all.

Indeed, after waffling for a couple of years, I now come down on the
"bitfields should be constants, not enum members" side. Semantically, an
enum is an enumerated set of values. Unless you include all the flag
combinations in that set, then technically (kFlagX | kFlagY) is no longer a
member of the set.

Instead I now recommend people do something like this:

typedef uint32_t StatusFlags;
const StatusFlags kFlag1 = 1 << 0;
const StatusFlags kFlag2 = 1 << 1;
...

Now you can use StatusFlags as the type everywhere, and do mathematical
operations on the flags as you please.

PK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Victor Khimenko

2014-09-24 16:34:07 UTC

Post by Daniel Cheng
The implicit integral conversion no longer works with strongly-typed
enum, but you can still static_cast them. Of course, to do so correctly,
one would probably want to use std::underlying_type in <type_traits> which
is a library feature...
Sounds like this is going to make piping together a series of flags a lot

less readable?
Indeed. But then these are two distinct usecases: either you are using

enums to name a set of possible choices (then "enum class" makes perfect
sense and you don't need to know values of these enums except maybe when
you are serializing them) or you are using enums as a replacement for a set
of "const int" consts (and in such case you don't really need to name the
type because it's just useless).

That's why I propose to allow "enum class { ... }" for the first usecase
and "enum { ... }" (note that type itself is not named!) for the second
one. You could still use "enum : uint64_t { ... }" to underscore that your
constants (when combined together) must form an uint64_t, but I'm not sure
if it's worth supporting it: because of integer promotion rules it'll not
add safety to the whole thing and will just confuse readers if you are not
using "auto" and I'm not sure we want to allow "auto" in such cases.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Philip Jägenstedt

2014-09-24 11:05:44 UTC

Yes, please! When trying to reduce compile time by removing includes a
few months ago, after the easy stuff it was usually enums that got in
the way of breaking dependencies further.

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Alex Vakulenko

2014-09-24 14:34:02 UTC

I personally like enum classes for their explicit namespace properties. So
the values themselves don't have to be kept unique inside the declaring
namespace:

////////////////////////////////////////////////
// This doesn't work
enum Answer {
kYes,
kNo,
};

enum UnsureAnswer {
kYes,
kNo,
kMaybe,
};

const char kYes[];
const char kNo[];

////////////////////////////////////////////////
// But this does
enum class Answer {
kYes,
kNo,
};

enum class UnsureAnswer {
kYes,
kNo,
kMaybe,
};

const char kYes[] = "yes";
const char kNo[] = "no";

And also it is nice to have a namespace when using those values:

void ProvideAnswer(Answer answer) {
if(answer == Answer::kYes) ...
}

+1 from me :)

Post by Philip JÃ¤genstedt
Yes, please! When trying to reduce compile time by removing includes a
few months ago, after the easy stuff it was usually enums that got in
the way of breaking dependencies further.
Philip

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Victor Khimenko

2014-09-24 14:54:14 UTC

Post by Alex Vakulenko
I personally like enum classes for their explicit namespace properties. So
the values themselves don't have to be kept unique inside the declaring
////////////////////////////////////////////////
// This doesn't work
enum Answer {
kYes,
kNo,
};
enum UnsureAnswer {
kYes,
kNo,
kMaybe,
};
const char kYes[];
const char kNo[];
////////////////////////////////////////////////
// But this does
enum class Answer {
kYes,
kNo,
};
enum class UnsureAnswer {
kYes,
kNo,
kMaybe,
};
const char kYes[] = "yes";
const char kNo[] = "no";
void ProvideAnswer(Answer answer) {
if(answer == Answer::kYes) ...
}
+1 from me :)
Indeed. I think that we could go even further and deprecate

"enum UnsureAnswer { ... };". Either "enum class UnsureAnswer { ... };" or
"enum { ... };" (for cases where enums are used to define consts which are
used not as elements of enum: bit flags, etc).

Use of the existing enums could be slowly converted to "Anwer::kYes" form
because that form is allowed for non-class enums, too, then, when all users
are converted, we could add "class" to enum declaration.

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

William Chan (陈智昌)

2014-10-01 21:48:53 UTC

Post by Philip JÃ¤genstedt

Do you have data you can share here on how forward declarations affect
build time? The reason I ask is because, internally within Google (for
Googlers, look for the internal C++ style mailing list thread titled
"Forward Declaration Efficiency Benefits") for our server-side code,
people have questioned this benefit and haven't found any supporting
evidence that forward declarations speed up the build. But Google's
internal code dependency graph is...special...and the build
infrastructure is special there too. But people are questioning the
benefit for that code base, which makes me wonder how much we benefit
in Chromium. If anyone has data, I'd love to see it.

Post by Mounir Lamouri
Allow enum to be marked as classes.
Being able to forward declare enums which can be very good for public
interfaces and generally speaking reduces headers inclusions.

Internally, many people are unhappy with forward declaring classes. We
don't allow forward declaring functions, variables, etc. Why classes?
For Googlers, you can read more details about this line of argument at
https://goto.google.com/fwd_decl_harmful. The public Google C++ style
guide does provide a list of some of the downsides at
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Forward_Declarations.

Anyway, I'm just pointing this out because there's _some_ chance that
the internal version of the style guide might change, although no one
has enough data on non-internal code bases to bother with changing our
public C++ style guide. But if people have data to share, that'd be
very informative.

Post by Mounir Lamouri
This is not about specifying a type on an enum for which I have no
opinion and no strong use cases.
http://en.cppreference.com/w/cpp/language/enum
-- Mounir
--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Kevin Schoedel

2014-10-01 22:09:03 UTC

Post by William Chan (éæºæ)
Internally, many people are unhappy with forward declaring classes. We
don't allow forward declaring functions, variables, etc. Why classes?
For Googlers, you can read more details about this line of argument at
https://goto.google.com/fwd_decl_harmful. The public Google C++ style
guide does provide a list of some of the downsides at
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Forward_Declarations.

I'd be equally happy without forward declarations (I'm looking for type
safety), but many of the arguments against forward declaring classes don't
apply to enums. Unlike classes, an 'enum class' forward declaration tells
you everything there is to know about the type, except the actual
constants.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Philip Jägenstedt

2014-10-02 09:35:06 UTC

Post by Philip JÃ¤genstedt

When we (David Vest and I) looked at this we were trying to reduce the
number of recompile steps after a typical gclient sync by focusing on
the most frequently touched headers. For example:
https://codereview.chromium.org/341193009
https://codereview.chromium.org/343593002

TBH, those didn't really pay off. Touching Document.h still recompiles
~1100 files. At the time it looked like the ability to forward declare
StyleResolverUpdateMode would allow the Document.h to be removed from
StyleEngine.h, but in the end the problem was solved differently:
https://codereview.chromium.org/358603002

As that CL shows, the other thing that gets in the way is inlining.

There may still be similar cases where enum classes would help, but
it's also possible to move the enums to a separate and less frequently
changing header, like RenderStyleConstants.h.

Philip

On Wed, Oct 1, 2014 at 11:48 PM, William Chan (陈智昌)

Post by William Chan (éæºæ)
Do you have data you can share here on how forward declarations affect
build time? The reason I ask is because, internally within Google (for
Googlers, look for the internal C++ style mailing list thread titled
"Forward Declaration Efficiency Benefits") for our server-side code,
people have questioned this benefit and haven't found any supporting
evidence that forward declarations speed up the build. But Google's
internal code dependency graph is...special...and the build
infrastructure is special there too. But people are questioning the
benefit for that code base, which makes me wonder how much we benefit
in Chromium. If anyone has data, I'd love to see it.

Post by Mounir Lamouri
Allow enum to be marked as classes.
Being able to forward declare enums which can be very good for public
interfaces and generally speaking reduces headers inclusions.

Internally, many people are unhappy with forward declaring classes. We
don't allow forward declaring functions, variables, etc. Why classes?
For Googlers, you can read more details about this line of argument at
https://goto.google.com/fwd_decl_harmful. The public Google C++ style
guide does provide a list of some of the downsides at
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Forward_Declarations.
Anyway, I'm just pointing this out because there's _some_ chance that
the internal version of the style guide might change, although no one
has enough data on non-internal code bases to bother with changing our
public C++ style guide. But if people have data to share, that'd be
very informative.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Viet-Trung Luu

2014-10-02 15:08:40 UTC

Post by Philip JÃ¤genstedt

I don't think the importance of forward declarations is build speed (nor,
relatedly, size of .o files).

Post by Mounir Lamouri
Allow enum to be marked as classes.
Being able to forward declare enums which can be very good for public
interfaces and generally speaking reduces headers inclusions.

Internally, many people are unhappy with forward declaring classes. We
don't allow forward declaring functions, variables, etc. Why classes?

See 2) below.

Post by William Chan (éæºæ)
For Googlers, you can read more details about this line of argument at
https://goto.google.com/fwd_decl_harmful.

I find that a dubious, one-sided document.

To my mind, there are two important uses for forward declarations (apart
from pure stupidity imposed by the language, such as allowing circular
references, even when the classes in question are in the same compilation
unit):

1) #includes in C++ are viral. Whatever you include in a header becomes
part of its public interface, whether you like it or not. I.e., if you
include a header, even if only for a private implementation detail, others
can and will rely on that include. If you remove that include, you'll have
to fix them. Compare .proto's "import" versus "import public".

Forward declarations allow you to avoid many such "private" inclusions,
even if they're not perfect (e.g., others will be able to rely on your
forward declaration). The only way of strictly avoiding this problem is
extreme and un-C++: separate things into interfaces and private impls, and
make factories for everything (and allocate everything on the head,
disallow construction of things on the stack or as member variables).

Being able to forward-declare enums also helps on this front -- e.g., if
you want to have a private member variable of some enum type (defined in
some other header).

2) There's a use-mention kind of distinction. It makes sense to, e.g., pass
pointers to objects around (i.e., "mention" objects) without knowing
anything about them. (E.g., a function/method may return a Foo*, and maybe
all the caller will ever do with that value is pass it on to something else
that takes a Foo* argument, without ever dereferencing it. There are
similar cases for other types.)

Types are different from functions and variables -- the latter are actual
instances of things.

Sadly, C++ breaks forward declarations (and/or makes them fragile) in
various ways: structs versus classes versus typedefs versus integral types,
templates, functions declared inline in headers, nested classes, and so on.
(Discussion of these breakages are the primary content of the above
document.)

Post by William Chan (éæºæ)
The public Google C++ style
guide does provide a list of some of the downsides at
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Forward_Declarations
.
Anyway, I'm just pointing this out because there's _some_ chance that
the internal version of the style guide might change, although no one
has enough data on non-internal code bases to bother with changing our
public C++ style guide. But if people have data to share, that'd be
very informative.

To unsubscribe from this group and stop receiving emails from it, send an

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Kevin Schoedel

2014-09-24 15:10:16 UTC

+1 for 'enum class', because some days you want your statically typed
language to do static type checking.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Matthew Dempsky

2014-10-15 03:26:39 UTC

Any resolution here?

I'd like to use enum class in https://codereview.chromium.org/659723002/,
but I just noticed "enum class" is still TBD in the Chromium style guide.

Post by Mounir Lamouri
Allow enum to be marked as classes.
Being able to forward declare enums which can be very good for public
interfaces and generally speaking reduces headers inclusions.
This is not about specifying a type on an enum for which I have no
opinion and no strong use cases.
http://en.cppreference.com/w/cpp/language/enum
-- Mounir
To unsubscribe from this group and stop receiving emails from it, send an

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Hendrik

2014-10-15 03:50:12 UTC

We haven't got this in yet? :(

There isn't really a good reason not to allow it and plenty of reasons to
allow it (strongly typed, avoid collisions, improves readability, allows
for forward declarations).

Proposal:

- All new enums must use enum class
- Naming: Foo::Bar (the k is distracting and redundant)
- enum class will not be used as bit-flags
- Forward declare if needed (i.e. you can avoid an include by doing so)

I think that covers everything discussed

Post by Matthew Dempsky
Any resolution here?
I'd like to use enum class in https://codereview.chromium.org/659723002/,
but I just noticed "enum class" is still TBD in the Chromium style guide.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Daniel Cheng

2014-10-15 04:04:22 UTC

Post by Hendrik
We haven't got this in yet? :(
There isn't really a good reason not to allow it and plenty of reasons to
allow it (strongly typed, avoid collisions, improves readability, allows
for forward declarations).
- All new enums must use enum class
- Naming: Foo::Bar (the k is distracting and redundant)
âI don't see a good reason to diverge from the Google style guide for

naming.

Post by Hendrik
- enum class will not be used as bit-flags
âSeems like this should be combined with the first bullet somehow.â
- Forward declare if needed (i.e. you can avoid an include by doing so)
I think that covers everything discussed

Post by Matthew Dempsky
Any resolution here?
I'd like to use enum class in https://codereview.chromium.org/659723002/,
but I just noticed "enum class" is still TBD in the Chromium style guide.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Matthew Dempsky

2014-10-15 04:57:51 UTC

Incidentally, one annoying usability quirk about "enum class" at the
moment: there's no operator<< for writing enum class values to an ostream,
which means you can't use (D)CHECK_EQ to test for equality on them.
However, DCHECK(enumval1 == enumval2) works okay.

Post by Daniel Cheng

naming.

Post by Matthew Dempsky
Any resolution here?
I'd like to use enum class in https://codereview.chromium.org/659723002/,
but I just noticed "enum class" is still TBD in the Chromium style guide.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Hendrik

2014-10-15 05:36:18 UTC

Post by Daniel Cheng

Post by Hendrik
- Naming: Foo::Bar (the k is distracting and redundant)
âI don't see a good reason to diverge from the Google style guide for

naming.

It's just my preference :) If this was your own new project, would you
rather see Color::Red or Color::kRed?

That said, I don't feel that strongly about this, let's get enum class in.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Matthew Dempsky

2014-10-15 05:39:00 UTC

Post by Hendrik
That said, I don't feel that strongly about this, let's get enum class in.

+1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Kevin Schoedel

2014-10-20 16:41:45 UTC

Post by Hendrik
That said, I don't feel that strongly about this, let's get enum class in.

Yes please. I don't think there are any objections to permitting enum class
per se, and I have a pending CL that would benefit greatly from type safety.

Discussion about unscoped enums and bit masks and naming conventions line
lengths can continue unabated.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Matthew Dempsky

2014-10-20 16:52:57 UTC

I've mailed out https://codereview.chromium.org/667483003/. It's awaiting
OWNERS approval.

Post by Kevin Schoedel

Post by Hendrik
That said, I don't feel that strongly about this, let's get enum class in.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Anton Vayvod

2015-03-23 18:36:57 UTC

Do I have to pass a forward declared enum class argument by
reference/pointer? If yes, will the compilers we use optimize it to pass by
value (if it's a const reference)? If no, forward declaring enums seems
like a downside to me because of passing a pointer and extra dereferencing.

Post by Matthew Dempsky
I've mailed out https://codereview.chromium.org/667483003/. It's
awaiting OWNERS approval.

Post by Kevin Schoedel

Post by Hendrik
That said, I don't feel that strongly about this, let's get enum class in.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Victor Khimenko

2015-03-23 18:41:36 UTC

Post by Anton Vayvod
Do I have to pass a forward declared enum class argument by
reference/pointer?

No. When you forward-declare enum you specify the underlying type (int,
uint64_t, or whatever), and you don't need to know anything else to pass
enums around.

Post by Anton Vayvod
If yes, will the compilers we use optimize it to pass by value (if it's a
const reference)? If no, forward declaring enums seems like a downside to
me because of passing a pointer and extra dereferencing.

Post by Matthew Dempsky
I've mailed out https://codereview.chromium.org/667483003/. It's
awaiting OWNERS approval.

Post by Kevin Schoedel

Post by Hendrik
That said, I don't feel that strongly about this, let's get enum class in.

--
--
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

'Peter Kasting' via blink-dev

2014-10-15 05:30:21 UTC

Post by Hendrik
- All new enums must use enum class
I am opposed to us mandating that.
- Naming: Foo::Bar (the k is distracting and redundant)
We should not diverge from the style guide.
- enum class will not be used as bit-flags
While I gave an argument above for why using const ints is IMO better than

enums, I don't think this is something we should mandate (and actually
"enum class" is significantly better for bitfields than just "enum" was
anyway).

PK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Hendrik

2014-10-15 05:42:41 UTC

Post by Hendrik
- All new enums must use enum class
I am opposed to us mandating that.

ugh, care to explain why? I can't think of any reason to use the old
broken enums :/
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

'Peter Kasting' via blink-dev

2014-10-15 05:48:01 UTC

Post by Hendrik
- All new enums must use enum class
I am opposed to us mandating that.

ugh, care to explain why? I can't think of any reason to use the old
broken enums :/

My personal argument: Saying enum class implies that it is important that
your values are of the particular specified type. For the most common use
of an enum, which is simply to enumerate a few distinct values, that's not
important. "enum class" is unnecessary, and its presence misleads the
reader about the intent of the author.

A different argument: whether or not you can think of any reason to use
non-class enums is not the point; we should only mandate enum class if
there are specific reasons that we should NOT ever use old-style enums.
The style guide should be brief; let's not add rules unless they are
critical.

But perhaps the argument that should really silence debate: the Google
style guide doesn't mandate this, and there is no reason Chromium code is
significantly different on this point, so there is no reason the Chromium
style guide should differ.

PK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Hendrik

2014-10-15 06:05:43 UTC

If 'Google style' is the final word on all decisions, we could have saved
time by using copy/paste.

Post by Hendrik
- All new enums must use enum class
I am opposed to us mandating that.

ugh, care to explain why? I can't think of any reason to use the old
broken enums :/

My personal argument: Saying enum class implies that it is important that
your values are of the particular specified type. For the most common use
of an enum, which is simply to enumerate a few distinct values, that's not
important. "enum class" is unnecessary, and its presence misleads the
reader about the intent of the author.
A different argument: whether or not you can think of any reason to use
non-class enums is not the point; we should only mandate enum class if
there are specific reasons that we should NOT ever use old-style enums.
The style guide should be brief; let's not add rules unless they are
critical.
But perhaps the argument that should really silence debate: the Google
style guide doesn't mandate this, and there is no reason Chromium code is
significantly different on this point, so there is no reason the Chromium
style guide should differ.
PK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

James Robinson

2014-10-15 06:12:44 UTC

Have you read the first paragraph of
http://www.chromium.org/developers/coding-style ? It's pretty clear on
this subject.

- James

Post by Hendrik
If 'Google style' is the final word on all decisions, we could have saved
time by using copy/paste.

Post by Hendrik
- All new enums must use enum class
I am opposed to us mandating that.

ugh, care to explain why? I can't think of any reason to use the old
broken enums :/

My personal argument: Saying enum class implies that it is important that
your values are of the particular specified type. For the most common use
of an enum, which is simply to enumerate a few distinct values, that's not
important. "enum class" is unnecessary, and its presence misleads the
reader about the intent of the author.
A different argument: whether or not you can think of any reason to use
non-class enums is not the point; we should only mandate enum class if
there are specific reasons that we should NOT ever use old-style enums.
The style guide should be brief; let's not add rules unless they are
critical.
But perhaps the argument that should really silence debate: the Google
style guide doesn't mandate this, and there is no reason Chromium code is
significantly different on this point, so there is no reason the Chromium
style guide should differ.
PK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Hendrik

2014-10-15 06:18:30 UTC

Well, that's too bad, I guess we're never getting more than 80 chars :)

Post by James Robinson
Have you read the first paragraph of
http://www.chromium.org/developers/coding-style ? It's pretty clear on
this subject.
- James

Post by Hendrik
If 'Google style' is the final word on all decisions, we could have saved
time by using copy/paste.

Post by Hendrik
- All new enums must use enum class
I am opposed to us mandating that.

ugh, care to explain why? I can't think of any reason to use the old
broken enums :/

My personal argument: Saying enum class implies that it is important
that your values are of the particular specified type. For the most common
use of an enum, which is simply to enumerate a few distinct values, that's
not important. "enum class" is unnecessary, and its presence misleads the
reader about the intent of the author.
A different argument: whether or not you can think of any reason to use
non-class enums is not the point; we should only mandate enum class if
there are specific reasons that we should NOT ever use old-style enums.
The style guide should be brief; let's not add rules unless they are
critical.
But perhaps the argument that should really silence debate: the Google
style guide doesn't mandate this, and there is no reason Chromium code is
significantly different on this point, so there is no reason the Chromium
style guide should differ.
PK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Daniel Cheng

2014-10-15 18:40:43 UTC

Actually, I think the primary benefit of enum class is that it doesn't
support implicit conversions to integers or booleans. So something like:

enum Status {
SUCCESS = 0,
IO_PENDING,
CANCELED,
FAILED,
}

if (DoSomethingThatReturnsStatus()) {
// ...
}

will be a compile error. While it's not explicitly mentioned in the C++
style guide, google3 internally seems to recommend the use of enum class
over plain-old enum for this very reason.

Daniel

On Tue, Oct 14, 2014 at 10:48 PM, 'Peter Kasting' via blink-dev <