On Fri, Mar 24, 2023 at 12:29 PM Giuseppe D'Angelo via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 24/03/2023 16:54, Andrey Semashev via Std-Proposals wrote:
> > Every change is breaking someone's intuition. Intuition is not factual,
> > it's personal. For example, when I see `T()` I do not assume zero
> > initialization at all, my first thought would be "it invokes the default
> > constructor of T", which may or may not produce something that is zero
> > initialized. If you want zero then you should spell zero.
> >
> > Anyway, I was stating that the change would not break existing code, and
> > I maintain this. Therefore it is not a breaking change, factually.
>
> The breaking bit is that, right now, for a type T, is_enum_v<T> == true
> always implies is_trivially_default_constructible<T> == true (and
> is_trivial_v<T> == true, etc.), as well as "value initializable by
> 0-filling". I wouldn't be surprised at all if there is code relying on
> this; adding user-defined constructors / defaults / ... to enumerations
> would break such code.

It wouldn't be unreasonable to argue that, if your code relies on
`trivially_default_constructible`, then that's what your code should
be asking for. If you're asking for something that currently implies
this, but doesn't actually ask for it, then your code is fragile.

That being said, making a scalar type not be trivially default
constructible is very odd, and should require motivation beyond "I
like it".