Hi Sebastian,

Thank you for taking your time to read my proposal and provide some commentary.

-----

> The templated class in its current form does not support bitfields, where one flag needs more than one bit.

I thought people would want to place those combinations inside the enum instead, like this following example:

enum class Website { Facebook = 1, Google = 2, FacebookAndGoogle = 3 };

Alternatively, the method `add_flag` could be overloaded with something akin to an std::initializer_list<T>?

Or, if you (or others) think it better, the Bitmask class itself could be extended with a method accepting a value of idempotent type:

enum class Website { Facebook = 1, Google = 2 };
constexpr std::Bitmask<Website> Fb_Goog = Website::Facebook | Website::Google;

std::Bitmask<Website> MyBitmask;
MyBitmask.add_mask(Fb_Goog);

> For bit-masking enums often constant flag-combinations are defined, including no flags, which equals 0 in the underlying type or all flags, which not necessarily (depending on whether the bits are all used) equals -1.

How about if the class gets a method `add_all_flags()` which just set the private member to -1? I am implicitly assuming the underlying type to always be unsigned, because inside my head that makes the most sense - perhaps this assumption is wrong?

The reason why I propose a template meta-function which checks that a scoped enum does not contain a zero value, is because I think for the reasons of type safety such a value should always be forbidden. This is the distinction between using an enum for bitmasking or for other purposes. I also choose to forbid adding an integer value to the bitmask class.

These are just design choices. Not necessarily the best option.?

-----

> When measuring the cardinality to add to the end or create end marker as =cardinality+1.

Maybe this is just me, but I don't quite understand why having an end marker is useful. Is this because it makes it easier to implement an iterator?

If a scoped enum has two values, and one of them is 0, then cardinality must still equal 2. And if an end marker should exist, it would have to be the third value inside the enum.

Or perhaps you mean to create a different type, e.g. `std::enum_end_marker<T>`, which makes a calculation based on cardinality, for some other purpose?

> Perhaps the end should not be defined as an enum value itself.

I agree on this. It would make code significantly more difficult to read, ie. I think it would only add unnecessary complexity. I think C++ is sufficiently complicated already. :)

-----

Best,
Alexander



________________________________
Fra: Std-Proposals <std-proposals-bounces_at_[hidden]> på vegne af std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>
Sendt: 31. juli 2023 14:00
Til: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Emne: Std-Proposals Digest, Vol 52, Issue 80

Send Std-Proposals mailing list submissions to
        std-proposals_at_[hidden]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
or, via email, send a message with subject or body 'help' to
        std-proposals-request_at_[hidden]

You can reach the person managing the list at
        std-proposals-owner_at_[hidden]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."


Today's Topics:

   1. Revision 1 of scoped enum enhancements (Alexander Christensen)
   2. Re: Revision 1 of scoped enum enhancements (Sebastian Wittmeier)


----------------------------------------------------------------------

Message: 1
Date: Sun, 30 Jul 2023 16:27:51 +0000
From: Alexander Christensen <alex_c007_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: [std-proposals] Revision 1 of scoped enum enhancements
Message-ID:
        <AM0PR09MB4291B27C94934ACA5F1430AFD404A_at_[hidden]>

Content-Type: text/plain; charset="iso-8859-1"

Hi all,

After a (longer than expected) period of thinking my initial proposal through, I here send a "revision 1".
I posted some time during winter 2021/22 a draft for how we can enhance scoped enums, and notably here - extended with bitmasking, as well as a lot of cleanup and testing.

It is a compiled pdf document of 15 pages, so I present a link:
https://github.com/alexpanter/cpp-enum-proposal/blob/master/revision-1/report.pdf

I'm really looking forward to your feedback.

Best,
Alexander

-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 2
Date: Mon, 31 Jul 2023 06:38:58 +0200
From: Sebastian Wittmeier <wittmeier_at_[hidden]>
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Revision 1 of scoped enum enhancements
Message-ID:
        <zarafa.64c73ae2.08d5.7133c44d3bb78d0c_at_lvps176-28-11-36.dedicated.hosteurope.>

Content-Type: text/plain; charset="utf-8"

Hi Alexander,

some feedback to your enum proposal:

?
Cardinality/automatic end

=====================

When measuring the cardinality to add to the end or create an end marker as =cardinality+1, there are (at least) three cases:

?- number of values defined so far

?- number of values defined so far - 1 (if the first value is 0)

?- maximum underlying value so far (if gaps are used)

?
Perhaps the end should not be defined as an enum value itself.

?
Bitmask enums

=============

For bit-masking enums often constant flag-combinations are defined, including no flags, which equals 0 in the underlying type or all flags, which not necessarily (depending on whether the bits are all used) equals -1.

In your notation those would be constants of the templated class-type. But perhaps it would make sense to mention those constants. Often those bitflag combination constants are currently put into the same enum as the flags and can contain 0. Your templated class would give those another type.

?
The templated class in its current form does not support bitfields, where one flag needs more than one bit.

?
Sebastian

?

?
-----Urspr?ngliche Nachricht-----
Von:Alexander Christensen via Std-Proposals <std-proposals_at_[hidden]>
Gesendet:So 30.07.2023 18:28
Betreff:[std-proposals] Revision 1 of scoped enum enhancements
An:std-proposals_at_[hidden];
CC:Alexander Christensen <alex_c007_at_[hidden]>;

Hi all,

?
After a (longer than expected) period of thinking my initial proposal through, I here send a "revision 1".

I posted some time during winter 2021/22 a draft for how we can enhance scoped enums, and notably here - extended with bitmasking, as well as a lot of cleanup and testing.

?
It is a compiled pdf document of 15 pages, so I present a link:

https://github.com/alexpanter/cpp-enum-proposal/blob/master/revision-1/report.pdf

?
I'm really looking forward to your feedback.

?
Best,

Alexander

?

--
 Std-Proposals mailing list
 Std-Proposals_at_[hidden]
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
End of Std-Proposals Digest, Vol 52, Issue 80
*********************************************