Keith Thompson
2016-03-22 01:30:58 UTC
I think this was mentioned here recently, but I can't find the article.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf
is a proposal for an enhancement to C's enumerated types, allowing the
programmer to specify the type used to represent a given enumerated
type. For example, you could write:
enum foo : unsigned short { zero, one two };
and an object of type enum foo would have the same representation as
unsigned short (rather than some implementation-defined integer type as
is currently the case).
I generally like the idea, but I have a few suggestions on the wording.
Currently each enumerated type is compatible with some integer type.
The proposal doesn't discuss type compatibility. Either "enum foo" in
the example above should be compatible with "unsigned short", or it
shouldn't be compatible with any integer type.
The syntax for a *enum-specifier* (the tokens between the ":" and the
"{") is too restrictive. It permits "unsigned short" but not "short
unsigned", unlike in any other context. Worse, it forbids the use of a
typedef.
Rather than elaborately reinventing the syntax of an integer type name,
it should simply use a *type-name*, with a constraint that it must be
the name of an integer type.
Should "enum : _Bool { ... }" be permitted?
Proposal two (which depends on proposal one but may be ignored without
affecting proposal one) uses the phrase "implicit cast". The correct
term is "implicit conversion".
It proposes removing the implicit conversion from integer types to enums
(only for enums defined with the new syntax), but permits implicit
conversion from enums to integers. I'm not convinced this asymmetry is
desirable. On the other hand, it's consistent with C++.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf
is a proposal for an enhancement to C's enumerated types, allowing the
programmer to specify the type used to represent a given enumerated
type. For example, you could write:
enum foo : unsigned short { zero, one two };
and an object of type enum foo would have the same representation as
unsigned short (rather than some implementation-defined integer type as
is currently the case).
I generally like the idea, but I have a few suggestions on the wording.
Currently each enumerated type is compatible with some integer type.
The proposal doesn't discuss type compatibility. Either "enum foo" in
the example above should be compatible with "unsigned short", or it
shouldn't be compatible with any integer type.
The syntax for a *enum-specifier* (the tokens between the ":" and the
"{") is too restrictive. It permits "unsigned short" but not "short
unsigned", unlike in any other context. Worse, it forbids the use of a
typedef.
Rather than elaborately reinventing the syntax of an integer type name,
it should simply use a *type-name*, with a constraint that it must be
the name of an integer type.
Should "enum : _Bool { ... }" be permitted?
Proposal two (which depends on proposal one but may be ignored without
affecting proposal one) uses the phrase "implicit cast". The correct
term is "implicit conversion".
It proposes removing the implicit conversion from integer types to enums
(only for enums defined with the new syntax), but permits implicit
conversion from enums to integers. I'm not convinced this asymmetry is
desirable. On the other hand, it's consistent with C++.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"