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.



Aleksej Penkov


From: Barry Revzin <barry.revzin@gmail.com>
Sent: Friday, March 24, 2023 18:37
To: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Cc: std-proposals <std-proposals@lists.isocpp.org>; Penkov Aleksej, JC-6 <Aleksej.Penkov@bmw.de>
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@gmail.com> wrote:

On Fri, Mar 24, 2023 at 1:12 PM Barry Revzin <barry.revzin@gmail.com> wrote:

On Fri, Mar 24, 2023, 10:33 AM Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On Fri, Mar 24, 2023 at 11:17 AM Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> 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."

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.