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.