--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8414e09f-34eb-870f-83f8-df2f75757c28%40scylladb.com.
I think this is inconsistent with what currently `enum class my_int_type : int {}' means. It's proper meaning is, that the enum will be of same size as integer (with no concrete enum labels specified). This has got nothing to do with inheritance.
You are missing a special case of enum class : some_type; the one where no members are specified.
For example there was a proposal to define std::byte as enum
class : uint8_t {}; with the meaning of introducing a new type
that has the same underlying implementation as uint8_t, but does
not implicitly convert.
In your case specified enum will 'inherit' enums from the boolean type (true, false).
Also one would have to consider what will :
enum class bar : bool {A,B,C,D}; mean? What is the meaning of true and false then?
I think better approach is to simply declare:
enum class my_int_type : int {DISABLED, ENABLED}; which is exactly same in meaning, but does not introduce any strange syntax, that introduces some inconsistency in standard.
--
2016-11-30 9:45 GMT+01:00 Avi Kivity <a...@scylladb.com>:
The trick of declaring type-safe integral types using `enum class my_int_type : int {}` seems to be quite popular. I propose extending it to bool:
enum class foo : bool {};
foo x = foo::true; // ok
x = false; // error
foo f1(), f2();
foo y = f1() || f2();
enum class bar : bool {};
enum class baz : bool {};
template <foo a, bar b, baz c> a_template_with_many_options { ... }
using with_my_options = a_template_with_many_options<foo::true, bar::false, baz::true>;
// more readable than a_template_with_many_options<true, false, true>;
Such a construct (enum class with no members, derived from bool) would have logical operators &&/||/! automatically defined, as well as explicit conversions to regular bool. I think it could help projects suffering from flag proliferation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8414e09f-34eb-870f-83f8-df2f75757c28%40scylladb.com.
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40mail.gmail.com.
We already have strong typedefs, their syntax is "enum class new_type : old_type {};"
On Wed, Nov 30, 2016 at 10:41 AM, Avi Kivity <a...@scylladb.com> wrote:
We already have strong typedefs, their syntax is "enum class new_type : old_type {};"
Um, no? I don't see what you mean. Using enum class seems hopelessly limited, being constrained only to integral types and requiring named enumerators (or horrible casts everywhere).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b58ddd77-6223-625e-9766-1fd073a83ad1%40scylladb.com.
Please re-read my original proposal, I think you're reacting to something completely different.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ccb56376-962b-ea9d-718e-710e2fc7300d%40scylladb.com.
enum class type : int{A,B,C,D};and not allowing:enum class typeB : bool{A, B, C, D};is very inconsistent.
"We already have strong typedefs, their syntax is "enum class new_type : old_type {};"This is not a strong typedef.
Please note, that allowing syntax:enum class type : int{A,B,C,D};
and not allowing:
enum class typeB : bool{A, B, C, D};
is very inconsistent. Inconsistency grows with total difference with semantics of such declaration.
Also
enum class typeB : bool; without labels is strong inconsistency in terms of semantics, because
enum class typeA : int; //here I mean forward declaration of the enum class. Here I can do forward declaration, because size is known.
enum class typeB : bool; //here I am declaring new type. No possible way of forward declaration (because this syntax is already used to declare new type)
mixing forward declaration syntax with declaration of completely new type for me seems very dangerous.
Using same syntax for different purposes in different context might be surprising for the programmer, and using same syntax, which semantics differ for particular type is just overkill.
Indeed strong typedefs are the solution, but strongly typed enums are not strong typedefs at all as already mentioned.
--
2016-11-30 12:33 GMT+01:00 Avi Kivity <a...@scylladb.com>:
Please re-read my original proposal, I think you're reacting to something completely different.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ccb56376-962b-ea9d-718e-710e2fc7300d%40scylladb.com.
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiG-HH7X3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27tg%40mail.gmail.com.
Fair enough.
We should not (further) encourage the (ab)use of `enum class` as a poor-man's strong typedef. By continuing to do so, we effectively dilute the need for real strong typedefs, thus ensuring that we'll never get them.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f13b4386-c91e-4737-9cab-7bb971382780%40isocpp.org.