This chapter says:

The Fixed(std::string&) constructor converts a string representation of a fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

But there is no constructor that accepts a non-const std::string&, the text should say

The Fixed(const std::string&) constructor converts a string representation of a
fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

Correct the spec text to match the source code

Add the missing "const" as described in the issue.

Double "to to" in the first sentence:

IDL bitset types are mapped to to C++ structs that meet the C++11 requirements for aggregate initialization.

Should be

IDL bitset types are mapped to C++ structs that meet the C++11 requirements for aggregate initialization.

Fix typo

As per issue description

The spec should mention how the IDL4-mentioned annotations impact the mapping, I think the spec should list at least @value, @default_literal, @default, @range @min @max @bit_bound @external

See IDL4 to CPP and the IDL4 spec itself

Add mappings for some more IDL 4 Standardized Annotations

New mappings for @value, @default_literal, @default, and @bit_bound – in each case drawing from uses in the beta IDL4-to-C++ mapping and/or XTypes.

In the specification an addition was made about the default argument when the union member has multiple legal discriminator values:

Union members associated with the "default" label and those associated with multiple labels may have multiple legal discriminator values. For these members, the modifiers (those that return void) have a second parameter which has the discriminator's type. This parameter has a default argument. For members associated with multiple labels, the value of the default argument is the value of the case label that appears first in IDL. For members associated with the default label, the value of the default argument is an implementation-defined value that selects the member.

There is nothing in the text that describes what happens when a discriminator value is passed which doesn't belong to the member, this is implicitly in the example code further down "u.obj(a, 2)", but this should be explicit in the text also, passing a not allowed discriminator should result in a BAD_PARAM exception

Add description of error handling for 2-parameter union modifier functions

To be consistent with the existing parts of the spec, make it clear that invalid parameters result in a BAD_PARAM exception.

Instead of `VariableExt(const Variable&, bool);` it should be `VariableExt(Variable, bool);` so that in the implementation we can use std::move, this is as all complex types are passed into the constructor of a struct

In example code, function signature of constructors is non-normative

In section 6.31.3 make it clear that the specific types of the constructor parameters (if they use pass by value or pass by const-reference) is up to the implementation.

The bitmask mapping is very basic, it doesn't give any type safety or more modern API. The spec should be improved, the <X>Bits type should be removed, only one type should be used. Also when there are multiple bitmasks with the same bitfield name they could result in a name clash. Maybe map to a enum class and add the operators ~,|,^,& for the enum class as inline operations to modify the enum class as a bitmask. At that moment the Bit type can be removed.

When time permits I will make a proof of concept for TAOX11

Defer breaking change to the bitmask mapping

The existing mapping in IDL-to-C++11 is based on DDS XTypes where it has been in a formal standard for a number of years.
There are certainly reasons to have a mapping that makes better use of the C++ type system, but this would come at a cost in terms of divergence from OMG precedent.

For some use cases it would be more efficient to map a IDL map to a std::unordered_map (see https://en.cppreference.com/w/cpp/container/unordered_map), maybe standardize an annotation which can be used to override the mapping to std::map to the type as specified by the annotation?

Defer

Other languages have similar issues like using TreeMap or HashMap in Java.

Defer resolution on this until standard annotation can be provided in the IDL 4 spec or the IDL Working Group has a common approach to use across language mappings.

using M2 = IDL::bounded_map<std::string, T, 20;

should be

using M2 = IDL::bounded_map<std::string, T, 20>;

Typo is not in base document

ptc/21-11-02 doesn't have this typo

The section says:

"For all primitive types, enums, and
reference types, an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

This is the only use of "primitive types" in the spec. "Basic Data Types" should be preferred. Would suggest:

"For all Basic Data Types [link/ref to 6.6 Mapping for Basic Data Types], enums [link/ref to 6.9 Mapping for Enums], and
reference types [link/ref to 6.7.1 Reference Types], an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

Update text in Arg Passing to refer to Basic Data Types

Update as specified in parent issue

The spec defines the type trait bit_bound as `std::integral_constant<uint32_t, b>`, but as bit_bound is maximal of 64, this could be `std::integral_constant<uint8_t, b>`

Update type used for bit_bound in bit mask traits

The integral_constant template from the C++ standard library should be instantiated with uint8_t instead of uint32_t

The bit_bound annotation can be applied to the enum, so the bit_bound and underlying_type traits should also be added to the enum

Add type traits for enums

Including this in the resolution to CPP1117-13.