Copy-list-initialization assignment has different results for structs with same type members but different definition order

#include <cstdint>

enum struct option_t : uint8_t
{
    INVALID         = 0,
    RESERVED        = 1,
    TEST_OPTION     = 2
};

struct Trace_1
{
    option_t   option  {option_t::INVALID};
    uint32_t   iter    {0};
};

struct Trace_2
{
    uint32_t   iter    {0};
    option_t   option  {option_t::INVALID};
};


int main()
{
    Trace_1 trace1{};
    Trace_2 trace2{};
    trace2 = {0};
    trace1 = {0};
}

Compiler Explorer link

For above code, the list initialization makes an assignment to one temporary object.
Trace_1 and Trace_2 have the same member types but differ in the declaration order; consequently the assignment result is different.
trace2 = {0} can compile but trace1 = {0} can't, with the error:

<source>:32:12: error: no viable overloaded '='
    trace1 = {0};
    ~~~~~~ ^ ~~~
<source>:15:8: note: candidate function (the implicit copy assignment operator) not viable: cannot convert initializer list argument to 'const Trace_1'
struct Trace_1
       ^
<source>:15:8: note: candidate function (the implicit move assignment operator) not viable: cannot convert initializer list argument to 'Trace_1'
struct Trace_1

I think the initializer 0 in the initialization list can be converted to the member types in both Trace_1 and Trace_2 without narrowing conversion, so the list initialization assignment should work. Any thoughts here?

In aggregate initialization, all of the initializers (in your case just 0) are used to initialize the data members in declaration order.

• for Trace_2, the 0 initializes iter, which is of type uint32_t (OK)
• for Trace_1, the 0 initializes option_t which is an enum class (ERROR)

You might assume that using 0 must be valid for Trace_1, because option_t{0} is valid (since C++17). However, the initialization of members takes place using copy initialization, as if by:

option_t option = 0;

There is no implicit conversion from int to option_t, so this is not allowed. It's not about whether 0 -> option_t is a narrowing conversion, it's about the syntax = 0 never being allowed for scoped enumerations (enum class).

On a side note, GCC gives us a much better error when attempting to use {0} to initialize (not assign) trace1:

error: cannot convert 'int' to 'option_t' in initialization
   24 |     Trace_1 trace1{0};
      |                    ^
      |                    |
      |                    int

Possible Solutions

// works because we now use direct list init, not copy init
trace1 = {option_t{0}};

// works because we now use the default member initializers in Trace_1
trace1 = {};

// same as above; more explicit, slightly redundant style
trace1 = Trace_1{};

Notes

Note 1: You don't need = {0} to value-initialize a struct in C++, only in C. Don't do it unless you want to be explicit about initializing the first member to zero.

Note 2: enum struct is allowed, but you might want to prefer enum class, since this is a much more popular style and will surprise fewer people.