The bitmask mapping allows misuse and is not really a modern API. At least for the users who map a struct to a class the bitmask mapping could for example use a strong enum (mappping now two bitmasks with the same member name will result in non compiling C++ code), but provide the operators ~, |, &, ^, |=, &=, and ^= to make it safe.

In the example code it lists
const int16_t& a_short()

This should be a return by value, using `const int16_t` will lead to a compiler warning, so it should be 'int16_t', all accessors should be checked

For anyone using the class mapping of a structure the spec should also provide a class mapping for a bitset, that way they have a consistent API. Also why is a inherited bitset not mapped to C++ inheritance, by removing the inheritance the inheritance relation can't be used in C++ also

The bit_bound annotation can also be applied to an enum, so add bit_bound/underlying_type also to the enum traits

Reporting this for bounded sequences, but very likely this has to be addressed for all bounded types. The spec says "NOTE—In any case, bound checking on bounded sequences may be performed at serialization time, raising an
exception or reporting an error if necessary", but this should be more strict to my idea, the bounds check must be performed, and the spec should specify which exception is raised when the bound is not respected

In the example code the destructors in classes that derive from a base should be marked override, not virtual, this applies to

• 6.18.4: Change "virtual ~Example();" to "~Example() override;" and "virtual ~OBV_Example();" to "~OBV_Example() override;"
• 6.20: Change "virtual ~Exception();" to "~Exception() override;" and "virtual ~SystemException();" to "~SystemException() override;"
• 6.25: Change "virtual ~MyLocalIF();" to "~MyLocalIF() override;"
• 6.26.6: Change "virtual ~A_skel ();" to "~A_skel () override;" and "virtual ~A_impl ();" to "~A_impl () override;"
• 6.26.8: Change "virtual ~TIE() = default;" to "~TIE() override = default;"

As there is no conversion implicit from a std::string_view to a std::string there is no possibility to easily pass now a IDL defined string to an operation expecting an IDL string input, will this mapping proposal work for the users?

This mapping defines the bound as std::integral_constant<size_t, b> but in most compilers size_t is 64bit where sequences/strings are bound to 32bit by IDL, so shouldn't size_t be replaced by uint32_t. If this is changed here, also check all other size_t types in this mapping

This new spec seems to try to support anonymous types (at least it doesn't disallow them like IDL to C++11), but how are then the type traits provided for anonymous types. For example the type

struct TopicA

;

Is there a way for the user to get the IDL traits for bound/is_bounded for the l5s member? If that is not possible for anonymous types this language mapping should make that clear, that anonymous types don't have a type trait.

With C++20 it would be nice when the mapping would specify a module mapping (see https://en.cppreference.com/w/cpp/language/modules).

The spec says " In addition to the methods as described in 6.14, the class has an explicit constructor accepting values for each struct member in the order they are specified in IDL.", all values should be by value, so better it is to day " In addition to the methods as described in 6.14, the class has an explicit constructor accepting values for each struct member by value in the order they are specified in IDL."

The underlying_type traits is maybe something to remove, std::underlying_type does the same at the moment bitmask is implemented using an enum. Also I am doubting whether an enum or enum class is the best mapping, have you tried to implement some user code, there is no operator bool() for example, some for checking if a bit is set we always have to cast. Maybe mapping to a class with operator is easier for the user, or use an enum class with operators.

The mapping for alternative struct mapping is lacking the constructors, member initialization, non-const accessors, description of how it works when using IDL4 struct inheritance, etc, see the IDL to C++11 language mapping for a full description

The spec gives:

const <MemberType>& <MemberName>() const

But for basic types/int this will result in a warning, for basic/enum it should be

<MemberType> <MemberName>() const

The spec says:

A public constant accessor method with the name of the union member that returns a constant reference to
its value:
const <MemberType>& <MemberName>() const;
Accessing an invalid union member may result in an undefined error.

A language mapping should be precise and very clear to my idea, the user should know what happens if an invalid union member is accessed, this could happen in some cases, the spec should specify which exception will be thrown so that the programmer can react on this, saying it is undefined is not enough.