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.

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

Barry