Hi team,

Thanks a lot for the discussion and your comments.
So am I right with the understanding that the idea is a ‘no-go’?

And thanks again.

Regards,
Aleksej Penkov

From: Barry Revzin <barry.revzin_at_[hidden]>
Sent: Friday, March 24, 2023 18:37
To: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Cc: std-proposals <std-proposals_at_[hidden]>; Penkov Aleksej, JC-6 <Aleksej.Penkov_at_[hidden]>
Subject: Re: [std-proposals] A proposal on default enum initialization


Sent from outside the BMW organization - be CAUTIOUS, particularly with links and attachments.

Absender außerhalb der BMW Organisation - Bitte VORSICHT beim Öffnen von Links und Anhängen.

________________________________

On Fri, Mar 24, 2023, 12:21 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]<mailto:arthur.j.odwyer_at_[hidden]>> wrote:
On Fri, Mar 24, 2023 at 1:12 PM Barry Revzin <barry.revzin_at_[hidden]<mailto:barry.revzin_at_[hidden]>> wrote:
On Fri, Mar 24, 2023, 10:33 AM Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Fri, Mar 24, 2023 at 11:17 AM Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]<mailto: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