C++: Provide constructors for auto-generated unions

[pavel-kirienko]

Instead of:

Ty_1 val;
val.foo = 123;
val.bar = baz;

go like:

const Ty_1 val(123, baz);

To facilitate immutability and URVO.

[asmfreak]

This partially works with brace-init, for everything except for unions.

// with C++17
const Heartbeat_1_0 hb{
  1244, // uptime
   {Health::NOMINAL},
   {Mode::WARNING},
   0x1
};

// with C++20 or extension
const Heartbeat_1_0 hb{
  .uptime=1244, // uptime
   .health={Health::NOMINAL},
   .mode={Mode::WARNING},
   .vssc=0x1
};

[pavel-kirienko]

Indeed, the members are public. I guess I am going close this and walk away with shame.

[asmfreak]

Unions would really need a constructor to initialize this way. We would need some kind of a tag dispatch to differentiate between different named variants.

// proposed syntax
const Value_1_0 val{Value_1_0::natural_16_tag, 1, 2, 3};

And variant construction is a problem right now. At the moment we can't constuct specific variant, we can only set value after:

Value_1_0 v;
v.set_natural_16({{10, 10, 0}});

[asmfreak]

I think the issue exists, just not for simple POD values as listed earlier.

[asmfreak]

There is also the issue of missing value init (as in the opening post)

[JLReitz]

PR #383 brings generated tag-type initialization constructors to c++ union message types with one limitation: variadic template parameters are not allowed, only the value type of the alternative being initialized may be provided.

const Value_1_0 val{
    cetl::in_place_index_t<Value_1_0::VariantType::IndexOf::natural_16>,
    Value_1_0::_traits_::TypeOf::natural_16{{1, 2, 3}}
};

This is to put a const allocator reference in the final constructor parameter, required for c++ flavors that do not have a default constructor convention. The allocator must be identified individually -- not part of a template parameter pack -- so that it can be referenced and stored for propagation during future alternative value emplacements.

// let allocator1 != allocator2, both are implementations of polymorphic_allocator
const Value_1_0 val{
    cetl::in_place_index_t<Value_1_0::VariantType::IndexOf::natural_16>,
    Value_1_0::_traits_::TypeOf::natural_16{{1, 2, 3}, allocator1},    // <-- allocator1 used to initialize parameter value
    allocator2    // <-- allocator2 stored by Value_1_0 object, passed to VariantType alternatives now and when setting new values
};

For language flavors that allow allocator default-construction, it is also possible to provide a value that is implicitly convertible to the stored alternative value. This works for any alternative value type that can be constructed with a single parameter that is not an initializer list. Note that this is a limitation for alternative value types that are composite messages, because their initialization value will also require an allocator parameter (see the use of allocator1 in the example above), and does not apply to alternatives that are POD types.

const ArbitrationID_0_1 val{
    cetl::in_place_index_t<ArbitrationID_0_1::VariantType::IndexOf::extended>,
    42U,    // <-- Implicitly converted to ExtendedArbitrationID_0_1
    allocator    // <-- Optional non-default allocator
};

C++17-pmr and 20-pmr will allow this. Cetl++14-17 does not because cetl::polymorphic_allocator is not default constructible.