Date: Mon, 10 Jul 2023 15:59:19 +0200
On 2023-07-10 15:49, Alejandro Colomar wrote:
> Hi Marcin,
>
> On 2023-07-10 14:52, Marcin Jaczewski wrote:
>> pon., 10 lip 2023 o 14:40 Alejandro Colomar via Std-Proposals
>> <std-proposals_at_[hidden]> napisaĆ(a):
> [...]
>
>>> An idea floats my mind from time to time, that having a [[flags]]
>>> attribute for such an enum would be useful to mark pow-of-2 cases. It
>>> could make that the enumerators are prev<<1 if the value is unspecified,
>>> instead of prev++ that is default for enums.
>>>
>>> However, I was never convinced by such idea because removing attributes
>>> should produce working code, and having the default values of an enum
>>> change depending on the attribute would be problematic. An alternative
>>> idea would be to use 'unsigned enum', since flags lists should be
>>> unsigned, to allow bitwise operations without UB.
>>>
>>
>> This could work if user need to do all work and attribute only to check
>> if given work was done correctly. Simply:
>>
>> ```
>> enum [[flag]] F : int
>> {
>> Two = 2,
>> Three = 3, //compilation error, expected 4
>> };
>> ```
>>
>> Ignoring this enum only allows compiling "invalid" programs,
>> it would not change behavior of "correct" ones.
>
> Yeah, that would be a possibility. However, I'm worried that in some
> cases it might be useful to have a sentinel UINT_MAX value even for
> flags enums, and that attribute would prohibit that. Also, sometimes
> one wants to define enumerators to be an alias to the combination of
> other enumerators. So it's a bit too restrictive.
>
> I think the more useful idea I've had regarding this is the following:
>
> unsigned enum foo_e {
> FOO_A, // = 1,
FOO_A = 1,
> FOO_B, // = 2,
> FOO_AB = FOO_A | FOO_B, // = 3,
> FOO_C, // = 4,
> FOO_D, // = 8,
>
> FOO_ALL = FOO_A | FOO_B | FOO_C | FOO_D, // = 15,
> FOO_ERR = -1 // = UINT_MAX
> };
>
> - Default for the first field is 1
Although this one could be removed, and have it default to 0 for the
first one, to reduce the differences with normal enums. Having an
explicit =1 in the first enumerator isn't so bad.
> - Default for consecutive fields is stdc_bit_ceil(prev+1);
> - Default underlying type is unsigned int instead of int.
>
> Cheers,
> Alex
>
> Hi Marcin,
>
> On 2023-07-10 14:52, Marcin Jaczewski wrote:
>> pon., 10 lip 2023 o 14:40 Alejandro Colomar via Std-Proposals
>> <std-proposals_at_[hidden]> napisaĆ(a):
> [...]
>
>>> An idea floats my mind from time to time, that having a [[flags]]
>>> attribute for such an enum would be useful to mark pow-of-2 cases. It
>>> could make that the enumerators are prev<<1 if the value is unspecified,
>>> instead of prev++ that is default for enums.
>>>
>>> However, I was never convinced by such idea because removing attributes
>>> should produce working code, and having the default values of an enum
>>> change depending on the attribute would be problematic. An alternative
>>> idea would be to use 'unsigned enum', since flags lists should be
>>> unsigned, to allow bitwise operations without UB.
>>>
>>
>> This could work if user need to do all work and attribute only to check
>> if given work was done correctly. Simply:
>>
>> ```
>> enum [[flag]] F : int
>> {
>> Two = 2,
>> Three = 3, //compilation error, expected 4
>> };
>> ```
>>
>> Ignoring this enum only allows compiling "invalid" programs,
>> it would not change behavior of "correct" ones.
>
> Yeah, that would be a possibility. However, I'm worried that in some
> cases it might be useful to have a sentinel UINT_MAX value even for
> flags enums, and that attribute would prohibit that. Also, sometimes
> one wants to define enumerators to be an alias to the combination of
> other enumerators. So it's a bit too restrictive.
>
> I think the more useful idea I've had regarding this is the following:
>
> unsigned enum foo_e {
> FOO_A, // = 1,
FOO_A = 1,
> FOO_B, // = 2,
> FOO_AB = FOO_A | FOO_B, // = 3,
> FOO_C, // = 4,
> FOO_D, // = 8,
>
> FOO_ALL = FOO_A | FOO_B | FOO_C | FOO_D, // = 15,
> FOO_ERR = -1 // = UINT_MAX
> };
>
> - Default for the first field is 1
Although this one could be removed, and have it default to 0 for the
first one, to reduce the differences with normal enums. Having an
explicit =1 in the first enumerator isn't so bad.
> - Default for consecutive fields is stdc_bit_ceil(prev+1);
> - Default underlying type is unsigned int instead of int.
>
> Cheers,
> Alex
>
Received on 2023-07-10 13:59:22