On Fri, Mar 24, 2023, 12:21 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> 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.)
>

It is not a big deal at all. Italicizing arbitrary words doesn't change
that. Moreover, this type trait doesn't even exist yet.

We changed aggregate in every standard, for instance.

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;
>

This, on the other hand, is a reason to be wary of the proposed change. Not
because E is incomplete, but rather because it is complete. Well, not the
above, that's ill-formed, but these alternatives

enum E : int;
enum class E;

both declare E as a complete type, which can then be constructed. So now
you'd potentially have this issue where E() could mean different things in
different contexts, and not even related to template shenanigans.

Barry

>