C++ Logo


Advanced search

Re: [std-proposals] A proposal on default enum initialization

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Fri, 24 Mar 2023 12:12:41 -0500
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.


Received on 2023-03-24 17:12:54