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. 

Not saying we should do this, but objecting to it on the basis of the type trait doesn't make much sense.