On Fri, Mar 24, 2023 at 1:12 PM Barry Revzin <barry.revzin_at_[hidden]> wrote:

> On Fri, Mar 24, 2023, 10:33 AM Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Fri, Mar 24, 2023 at 11:17 AM Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On 3/24/23 18:05, Oleksandr Koval via Std-Proposals wrote:
>>> > Actually, allowing default values can break
>>> > existing code because right now `Enum e{};` always means e = 0, after
>>> > your change the value will be different.
>>>
>>> No existing code uses "default:" for marking the default enum value
>>> because currently this syntax is invalid. So this is not a breaking
>>> change.
>>>
>>
>> It's a breaking change to the programmer's intuition, though, if they're
>> used to `T t = T();` meaning "zero-initialization" for scalar types.
>> It certainly interacts with Giuseppe's recent P2782 "Type trait to detect
>> whether a type is trivially value-initializable by zero-filling."
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2782r0.html
>> Right now that trait is obviously `true` in practice for all integer and
>> enum types, at least on sane platforms; and P2782R0 proposes that it should
>> be formally set in stone for integer and enum types forever.
>> Aleksej is proposing to make that trait not-true for *some* (but not
>> all) enum types.
>>
>> Anyway, that's a game-ending objection to the semantics IMHO;
>>
>
> Uh, what?
> Surely if we added this facility to the language, we'd also change the
> corresponding type trait (which is itself also just a proposal right now)
> to do the right thing.
>

Yes, but the necessity of changing a type trait is a big enough deal that
it counted as game-ending IMHO. (Like, even if changing the *abstract
properties* of enum types isn't perceived as a big deal, changing the
*concrete* data exposed by an STL type trait seems like a bigger deal, to
me, today.)
I suppose it's slightly mitigated by the fact that P2782R0's
`is_trivially_value_initializable_by_zero_filling_v<T>` is proposed *not*
to work on incomplete types. So
    enum E;

static_assert(std::is_trivially_value_initializable_by_zero_filling_v<E>);
is proposed to be UB, not statically "true". If you have to wait for the
complete type definition of `E` anyway, then it's easier to permit that
definition to change `E`'s trivial-value-initializability.

my $.02,
Arthur

>