The spec doesn't describe exactly to which element types @optional should be possible, leaving it to the vendor implementation. The spec should describe to which element type this annotation (but also the others) should be applied, struct members sounds logical, but what about union members, attributes, exception members?

If the numeric type is annotated by range:

    @range(min=1, max = 10) long f1;

or min

    @min(1) long f1;

or max

    @max(-1) long f1;

but does not specify a default, what is the default value since it cannot be 0.

The spec describes that with CORBA an invalid usage of union can result in a CORBA::BAD_PARAM exception, for bounded string/vector also a CORBA::BAD_PARAM, but when not using CORBA when IDL4CSP11-9 is resolved a different exception is thrown for an union (for vector it seems this still has to be added also). When a user now has appliation code that uses IDL defined data types with and without CORBA their exception code is different. In order to achieve portability of user code I think the spec should define a omg::bad_param alias type which maps to CORBA::BAD_PARAM or the selected std exception. That way user code can be written portable when the user has data types defined by IDL and wants to support use cases with and without CORBA

The spec describes that with CORBA an invalid usage of union can result in a CORBA::BAD_PARAM exception, for bounded string/vector also a CORBA::BAD_PARAM, but when not using CORBA when IDL4CSP11-9 is resolved a different exception is thrown for an union (for vector it seems this still has to be added also). When a user now has appliation code that uses IDL defined data types with and without CORBA their exception code is different. In order to achieve portability of user code I think the spec should define a omg::bad_param alias type which maps to CORBA::BAD_PARAM or the selected std exception. That way user code can be written portable when the user has data types defined by IDL and wants to support use cases with and without CORBA

the code examples use = and {} to initialize the constants, recommend to make this consistent by always using {}

The spec in 7.4 says that only basic types/enum should be passed by value for an in argument, but that should also include all shared_ptr types, see https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ for some information (more can be found on the internet).

the code examples use = and {} to initialize the constants, recommend to make this consistent by always using {}

The spec in 7.4 says that only basic types/enum should be passed by value for an in argument, but that should also include all shared_ptr types, see https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ for some information (more can be found on the internet).

A few remarks on 7.17.3:

• formatting of code in text is not done
• what is the impact of range when applied to a typedef of a basic type on all argument passing rules when that typedef is passed with a function, stored in an union or exception?
• how should min/max be implemented, shouldn't also omg::types::ranged be used?
• what should be done when min/max but also range are used as annotation?

I find it not very maintainable to extend in this spec silently the IDL to C++11 language mapping. In the v1.7 revision I think all is already mapped, so I propose to remove D.3 completely from this spec

Not sure where (not necessarily in the noted paragraph) should include a reference to an electronic mapping file as an example. Could also include test sample IDL and corresponding C++ output. This should probably be informational and could also be in an Annex. The key reason is to show the actual transformation as well as a test/verification of the mappings. Perhaps also include versions of tools/compiler used in which the transformations were validated. In addition unit tests could be referenced or included as informative content to the spec.

Prior to C++20, the following template cannot be instantiated:

template <typename T, const T thingy>
class MyTemplate {};

MyTemplate<double, 5.0> x;

Keys of maps can be any IDL type. How should the generated C++ code support key comparison of any type?

Not sure where (not necessarily in the noted paragraph) should include a reference to an electronic mapping file as an example. Could also include test sample IDL and corresponding C++ output. This should probably be informational and could also be in an Annex. The key reason is to show the actual transformation as well as a test/verification of the mappings. Perhaps also include versions of tools/compiler used in which the transformations were validated. In addition unit tests could be referenced or included as informative content to the spec.

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

Prior to C++20, the following template cannot be instantiated:

template <typename T, const T thingy>
class MyTemplate {};

MyTemplate<double, 5.0> x;

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

Keys of maps can be any IDL type. How should the generated C++ code support key comparison of any type?

Spec says:

If the union has a default case, the default constructor shall initialize the discriminator, and the selected
member field following the initialization rules described in Clause 7.2.4.3.1. If it does not, the default
constructor shall initialize the union to the first discriminant value specified in the IDL definition.

But when there is an implicit default member, that should be selected, for example, the example below (

  enum DataType
  {
    dtEmpty,
    dtLong,
    dtShort,
    dtString,
    dtPoint,
    dtTrack,
    dtGlobal
  };

  union Data switch (DataType)
    {
      case dtLong: long longData;
      case dtShort: short shortData;
      case dtString: string stringData;
      case dtPoint: string pointData;
      case dtTrack: string trackData;
      case dtGlobal: string globalData;
      // by default (implicit), empty union
    };

A few remarks on 7.17.3:

• formatting of code in text is not done
• what is the impact of range when applied to a typedef of a basic type on all argument passing rules when that typedef is passed with a function, stored in an union or exception?
• how should min/max be implemented, shouldn't also omg::types::ranged be used?
• what should be done when min/max but also range are used as annotation?

I find it not very maintainable to extend in this spec silently the IDL to C++11 language mapping. In the v1.7 revision I think all is already mapped, so I propose to remove D.3 completely from this spec

Spec says:

If the union has a default case, the default constructor shall initialize the discriminator, and the selected
member field following the initialization rules described in Clause 7.2.4.3.1. If it does not, the default
constructor shall initialize the union to the first discriminant value specified in the IDL definition.

But when there is an implicit default member, that should be selected, for example, the example below (

  enum DataType
  {
    dtEmpty,
    dtLong,
    dtShort,
    dtString,
    dtPoint,
    dtTrack,
    dtGlobal
  };

  union Data switch (DataType)
    {
      case dtLong: long longData;
      case dtShort: short shortData;
      case dtString: string stringData;
      case dtPoint: string pointData;
      case dtTrack: string trackData;
      case dtGlobal: string globalData;
      // by default (implicit), empty union
    };

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.

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

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?

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.

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;"

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

The @value annotation does not fully specify the behavior. That includes:

• The behavior for unannotated values.
• The behavior for repeated values. Is it possible like in C++?

DDS-XTYPES does specify the behavior of @value and such description should be added to IDL:

7.3.1.2.1.5 Enumerated Literal Values
Prior to this specification, it was impossible to indicate that objects of enumerated types could be stored using an integer size other than 32 bits. This specification uses the @bit_bound annotation defined in Sub Clause 8.3.4.1 of [IDL] for this purpose.

It is important to note that the value member of the annotation may take any value from 1 to 32, inclusive, when this annotation is applied to an enumerated type. Furthermore, prior to this specification, it was impossible to provide an explicit value for an enumerated literal. The value was always inferred based on the definition order of the literals. That behavior is still supported. However, additionally, this specification allows enumerated literals to be given explicit custom values, just as they can be in the C and C++ programming
languages. This can be done by means of the @value annotation defined in Sub Clause 8.3.1.5 of [IDL], which may be applied to individual literals.
It is permitted for some literals in an enumerated type to bear the @value annotation while others do not. In such cases, as in C and C++ enumerations, implicit values are assigned in a progression starting from the most-recently specified value (or an implicit value of zero for the first literal, if there is no previous specified value) and adding one with each successive literal.

According to IDL4, annotations like range need to specify the arguments that are set. However, in the example we include for the mapping of @range we don't specify min and max in the arguments.

We need to address that as follows:

struct StructureOfRangedValues {
    @range(min=-10, max=10) long x;
};

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 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."

For instance is this legal:

struct S

;

typedef @min(2) long MyMin;
typedef @max(5) MyMin MyMinMax;
typedef @default(3) MyMinMax defaultedMyMinMax;

Each annotation specified, either pre-defined or user-defined/custom, should discuss how it interacts with the IDL4 grammar such that the annotation has the desired effect (e.g. @range on a union).

What happens when the following is present in an IDL file:

typedef @min(2) @max(1) long Huh;

The mapping of external in this section is not similar to 7.17.4. In 7.17.4 it is a std::shared_ptr, so a pointer to something which is shared, when copying the struct where the external is a member of the external data will not be copied, just a refcount increment, but in D2.3.4 it is descriibed that when the struct which contains the external member is copied a deep copy is done. Also what is exactly "copy functions", is that the copy constructor or something else? This looks very unspecified, the user doesn't know the exact API and the semantics should be the same as in 7.17.4

As far as I understand it enum_prefix/enum_postfix are a way to change the enum mapping but I don't understand why, because the enums itself are added to the enclosing module, so the following IDL is already illegal, red can't be defined twice
scope. For example the following IDL is illegal

enum Colors { red, green, blue };
enum Colors2 { red, green, blue };

See IDL4.2, chapter 7.5.2, search for "Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that

The text describes that the destructor and other constructors are protected, but the example code shows them all public, the C++ code should be updated to match the text

For IDL type VT1 the example code is not correct:

• virtual is missing for all pure virtual methods
• a_long_attr is an attribute, so "int32_t& a_long_attr() = 0;" should be removed

The mapping says "IDL strings shall be mapped to C++ std::string, or to a type named omg::types::string that delivers std::string semantics", but when I now have CORBA and use an interface with operation "void set_string (in string text);", what is now the C++ signature I have to override in my servant implementation, it could be "void set_string(const std::string& text) override;", or "void set_string(const omg::types::string& text) override;" which could lead to portability issues when some vendor uses std::string and another omg::types::string. For defining data it doesn't make a real difference, but it is a problem when using CORBA

The valuetype VT2 is defined in IDL, but the example C++ code is not correct, it says

class VT2 : public virtual VT1 {
public:
virtual void op() = 0;
virtual int32_t third_long() const = 0;
virtual int32_t& third_long() const = 0;
virtual void third_long(int16_t value) = 0;
};

But it should be

class VT2 : public virtual VT1 {
public:
virtual void op() = 0;
virtual int32_t third_long() const = 0;
virtual int32_t& third_long() = 0;
virtual void third_long(int32_t value) = 0;
};

Why does this example code for "C.2.1.2.4 Naming Data Types" map the IDL struct to a C++ class, that is the alternative mapping, but as far as I understand it the mapping prefers to map a IDL struct to a C++ struct by default

The section is silent on maps.

A link is broken, it mentions:

Maps shall provide the following specializations for the type traits defined in Clause Error: Reference source not found:

The text:
"Inherits std::integral_constant<uint32_t, b> where b indicates
the bit_bound of the bitmask."

should instead state

Defines value - Where the value is mapped as the underlying bit_bound of the bit mask.

As all types in the spec are lower case, shouldn't IDL fixed be mapped to C++ fixed (all lower case)

The example for interfaces full lists in IDL the attribute "an_attribute", but the cod example uses "attribute", which is not correct

In the example code there is "using Length = long;", but long is not portable, shouldn't be this be int32_t?

Given this is the old CORBA style, wouldn't it be more consistent to use CORBA::TinyShort and CORBA::UTinyShort, that matches the other types as defined in D.2.1.5

Can a default annotation be applied to string types (bounded and unbounded)?

The IDL 4 spec states the default bit_bound is 32 bits the C++ mapping document states:
IDL bitmask declarations shall be mapped to two C++ type names:

• An unscoped enum named <Bitmask>Bits with an explicitly defined underlying type. That underlying type
  is the smallest mapped unsigned integer type that has sufficient bits for the bit_bound of the bitmask:
  uint8_t, for values between 1 and 8; uint16_t for bit_bound values between 9 and 16; uint32_t, for
  values between 17 and 32; and uint64_t for values between 33 and 64. The <Bitmask>Bits enumerators
  are the values defined in the scope of the IDL bitmask, with each enumerator explicitly initialized to its
  corresponding integer value.

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.

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 says for bounded strings " For interoperability purposes, implementers shall always define omg::types::bounded_string<N>, which may be declared as an alias to std::string". There is a problem when a bounded string is mapped to just a typedef/using of a std::string. At that moment it is not a distinct type so the traits will not work, as example, when defining this IDL

typedef string<5> bounded_bar1;
typedef string<5> bounded_bar2;

And both map to just std::string, the following code will not work correctly

if (traits<Test::bounded_bar>::is_bounded ()) {}
if (traits<Test::bounded_bar>::bound () == 5) {}

In the example code it lists "AnException(int32_t error_code, const char* what)

", but the what argument is not described anywhere, it is not in IDL, where is it coming from?

1.
In table 7.1 5th row (struct is_bounded) right column:

Indicates whether a type is bounded or not.,

→ Remove comma at end.

2.
In section A.1.7.4 TypeCode Replacement, there is a small typo,

Omg::types::ref_type<CORBA::TypeCode> type() const;

The beginning should be omg:: not Omg::.

3.
Section title,
D.2.1.3.3 Bitmask Tye

→ Bitmask Type

4.
In section D.3.1.3.2 Bitsets,

IDL biset types shall be mapped as defined in Clause 7.14.3.2 of this specification.

→ bitset types

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

The spec should be describe that bitmasks do follow the same argument passing rules as a enum/basic type, for an in argument they should be passed by value. Also for union accessors it should describe that they follow the enum rules

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

Should the C++ mapping document specify that @value annotations, if specified for one field, MUST be used on all fields.

Section 7.2.4.2 Template Types makes available types in namespace omg::types that may be used as substitutes for the native C++ types.

The same does not apply to section 7.2.4.4 for arrays.
Please change the first phrase in 7.2.4.4 to:

The spec maps a constant within an IDL interface to a constexpr member, but this doesn't compile:

i.cpp:8:1: error: non-static data member ‘PI’ declared ‘constexpr’
8 | constexpr double PI = 3.14;

it is not clear what the traits is_bounded/bound are for non string/sequence types, for example a long. The spec says the trait is empty, but it is there, what is the value then. When looking at the std traits, it seems better that is_bounded returns false_type (follows https://en.cppreference.com/w/cpp/types/is_bounded_array) and bound returns 0 (follows https://en.cppreference.com/w/cpp/types/rank)

There are currently a number of numeric annotations presented in the spec. These are annotations that impact the numerical behavior of a type (like its allowed ranges). Right now, the spec doesn't clearly specify where these annotations may be applied and where they may not be applied. It would be wise to extend the section that introduces these annotations with a paragraph that clearly lays out these restrictions.

It is unclear whether or how annotations such as "unit" and "range" apply to the values in an array or sequence. Other annotations may have similar ambiguity.

Do they apply to each contained value, or do do they somehow apply to the aggregate value? What about multi-dimensional arrays or nested sequences?

Does the range somehow apply to the sequence length, perhaps as a minimum?

Where do they belong in the array or sequence definitions – before the keyword, before the type name, or somewhere else?

Do the different locations accept different annotations? Do the annotations change meaning depending on location?

The spec says for bitfield " list of identifiers (<identifier>*).", shouldn't this be 1 or 0 identifiers, what if the user specifies 4 identifiers, how to separate them, what is the meaning?

The spec doesn't say anything about bitmask bit_value scoping. I think the spec currently allows

bitmask MyBitMask

;

This is problematic when a bitmask maps to an enum in C++. As a bitmask is pretty similar to an enum I do ask the following, in section 7.5.2 it says:

Enumeration value names are introduced into the enclosing scope and then are treated like any other declaration in that scope.

What about a bitvalue, shouldn't this also be done for a bitvalue (the members of a bitmask), that would allow a safe mapping to an enum in C++.

The spec should be clear about where bitmasks are introduced, within the bitmask scope itself, or in the enclosing scope

There is nothing explained what the expected behavior is when an annotation is applied at multiple levels, for example see the changed example from 8.3.3, what is the range for Foo:bar2, is it min=10,max=20 or min=5,max=10

@range (min=10, max=20)
typedef long MyLong;
...
struct Foo

;

Section 8.3.3
Has the normative example;

@range (min=10, max=20)
typedef long MyLong;

It is unclear to me if the annotation applies to the typedef keyword or to the type in the typedef definition.

As a OMG IDL user, I have messages that treat NaN or infinity as a significant value. I would like to specify this as a default for a field.

Currently, the OMG IDL specification says that a floating point value must include an integer part. It does not mention how to set or use special floating point values.

Per IEEE-754, there are a few types of NaN. It would be desirable for OMG DDS IDL to interpret NaN as a quiet NaN, which matches C++ and Python.

In ROS-IDL, it would look like this:
float32 float32_nan NaN
float64 float64_nan nan

In ROS 2, I proposed an implementation that sets NaN. In the IDL generator, it creates the following IDL file, which is not supposedly valid according to the standard:

module rosidl_generator_tests {
module msg {
module NanValueConstant_Constants

;
struct NanValueConstant

;
};
};

Can the specification be amended to support NaN, +inf, and -inf? This is blocking implementation in ROS 2.

Currently only TRUE or FALSE are allowed boolean values, but why not allow true and false (all lower case) as values

The spec clearly specifies that when a union has an explicit default member, then this member should be chosen in its default constructor. When this is not the case, it would pick the first available case that is listed for its first available member.
However, it makes sense that if there is an implicit default member, then it is picked by the default constructor for the union.
Finally, it should be stated that you cannot overrule in any way what member the default constructor of a union will pick by using the @default annotation on any specific member,

Should the IDL4 grammar specify that @value annotations, if specified for one enum field, MUST be used on all enum fields?
Regardless of whether we make this restriction, the specification should clearly state what happens when one field is annotated, but the next one is not.

The annotation optional impacts the language mapping, for example in C it results in a pointer, with C++11 it could be a IDL::optional<>. The usage of an annotation is very weak in terms of semantics, it is much better to use a new optional keyword as optional heavily impacts the type presented to the programmer. Adding optional will break existing user code, it is not only something that is checked by a concrete middleware.

The

The spec is silent about the relationship between min/max/range annotations and the default value. When I have an unsigned long and define min=10/max=20, is that legal without specifying a default value annotation? The default of an unsigned long is zero, so what should be generated in the code now as default? Or should the spec say that when min/max/range are used and the default value of the type is not in the range of those default should be specified by the user?

The IDL 4.2 page has a download link for the spec as published as an ISO: https://www.omg.org/spec/IDL/ISO/19516/PDF

All (?? - verification left as an exercise but there's 926 instances) the internal document links look to be screwy.

Search for e.g. "Reference source not found"

An example (from page 102):

Annex A
Consolidated IDL Grammar
This annex gathers all the rules from all the building blocks.
Error! Reference source not found.:
Error! Reference source not found. Error! Reference source not found.
Error! Reference source not found. Error! Reference source not found.
Error! Reference source not found. Error! Reference source not found.
... etc...

For all c++ code in this chapter the destructor should be override, not virtual

The raise operation should be _raise, that way any derived user exception can have a raise member, similar to _name and _rep_id. Looks an oversight when adding the code from TAOX11, we use _raise always there

The data retrieval of described rules of constants entity during document compilation failed.

With a bitset/bitfield I assume you can use @default to specify a default value, would be nice if a binary constant could be used, as with C++, a binary constant consists of a sequence of ‘0’ and ‘1’ digits, prefixed by ‘0b’ or ‘0B’ for example 0b101010

IDL 4.2 says for bitset the following, but to our idea the IDL spec goes to far, how the data is organized in memory is something IDL can't enforce, probably not all programming languages provide such a direct way to control the memory layout. Middleware could control how a bitset is transferred on the wire, but I think IDL should not enforce the layout

Bit sets are sequences of bits stored optimally and organized in concatenated addressable pieces called bit fields,
themselves stored optimally. "Stored optimally" means that one bit uses just one bit in memory. "Concatenated" means
that each bit field will be placed in memory just after its predecessor within the bit set (no alignment considerations
apply).

I assume that in a map keys may not be unique (this should be added to 7.4.13.4.3.1), in case that is a restriction for a map, I propose to add a multimap which allows keys to be duplicate.

Now that with IDL4 the user can use @default to specify a specific default it would be good to also specify the default for all basic types when no @default is used. That way the user (or tool) can make a decision whether it must use @default in IDL or not

In the footnote the link to http://www.bipm.org/en/measurement-units/ is mentioned, but this seems to be dead, the link should probably be https://www.bipm.org/en/measurement-units/

Add ruby as language, there is a formal OMG language mapping for that, maybe just add all programming languages for which the OMG already has a formal language mapping

For int8 a new signed_type_int is defined, but I think it should just do the following so that anywhere where octet is used now int8 can be used

<octet_type> ::+ "int8",

Currently the key element type for maps is the same as the value element type, but that looks to be open, this allows for example a union, struct, reference, or other complex type as key type, all of them lack a comparison operator, very likely it is better to define a special map_key_type_spec just as we have for the union as switch_type_spec

IDL 4.2 syntax supports inheritance of only interfaces, valuetypes, and structures.

There are multiple scenarios where it would be useful to inherit other types, specifically Unions and Enumerations.

(1) Inheritance of unions

This would be very useful in some specs where unions are automatically generated. For example unions are created interface definitions in DDS-RPC and derived interfaces would like to use unions that "inherit" the unions in the base interfaces.

This would be useful when a "derived" union wants to add some more cases to the base union.

The derived union would have to use the same discriminator type. All it can do is add new discriminator cases that do not conflict with the non-default discriminator in the base union.

It can add a default case if not present in the base union.

Proposed syntax would be:

union DerivedUnion : BaseUnion {
    case 1 :
       Case1Type case1meber;
...
};

(2) Inheritance of enumerations

This is useful to add literals to an existing enumeration without touching the original definition.

The literals on the derived union would be constrained to not conflict the literals in the base class.

Proposed syntax would be:

enum DerivedEnum : BaseEnum {
    AdditionalLiteral1,
    ...
};

For bitmask the spec says "By default, the size of a bit mask is 32", but what unit is 32, I assume the spec wants to say "By default, the size of a bit mask is 32 bits"

All constructed types map to a C+11 class with accessors, but the new bitset mapping is an exception now, it delivers no accessor methods which gives a different API to the programmer. We propose to map to a class with accessors, similar like struct, or fastdds does in their implementation (see https://fast-dds.docs.eprosima.com/en/latest/fastddsgen/dataTypes/dataTypes.html#bitsets). Also the IDL inheritance is gone in C11, propose to use a derived class, so that in the C+11 code there is also an inheritance

There is a general need to document the IDL. However the IDL language does not provide any standard way to do this. As a consequence people may be forced to define custom annotations which would preclude the use across projects and/or development of general tools that are documentation aware.

To remediate this the suggestion is to add some built-in annotations that maybe used to document the IDL. For example the @documentation annotation below:

@annotation documentation {
    string value default "TBD";
};

This annotation could applied to a type declaration or to a member / element, as in:

@documentation("This documents the type Foo")
struct Foo {
    @documentation("documentation for member m1")
    long m1;
    @documentation("documentation for member m2")
    long m2;
 };

@documentation("This documents the type MyEnum")
enum MyEnum {
    @documentation("documentation for literal L1")
    L1,

    @documentation("documentation for literal L2")
    L2
 };

When map/bitset/bitmask are added it looks formal_parameter_type is not extended to allow these new types to be used as templated module arguments.

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.

Section 7.4.13.4.3.1 defines IDL Maps but doesn't specify:

• Which types may be keys
• If maps need to de-duplicate equivalent entries
• If maps need to preserve order

The most essential of these is the first. It's currently unrestricted but this causes problems for language mappings where some additional operations (like less-than or equal-to) must be defined for these types. In order to prevent different language mappings adding different (conflicting) restrictions, the IDL spec should define this.

One approach to this would be that each building block should define how its types can (or can't) be used in maps. For example: everything in core data types is allowed; interfaces are not allowed; valuetypes are not allowed; etc.

The section Imports contains

The effects of an import statement are as follows:

• [...]
• Importing a name scope recursively imports all name scopes nested within it.

This looks counter intuitive to me.

Example:

module commontypes {
   module nested1 {
      enum RGBColor { RED, GREEN, BLUE };
   }
   module nested2 {
      enum TrafficLight { READ, YELLOW, GREEN };
   }
};

What happens if another module does "import commontypes"?

If, as the standard says, all name scopes nested within "commontypes" are recursively imported then this would lead to errors:
The enum values RED and GREEN would be directly visible and would be in conflict with each other.

The 'Group of Annotations General Purpose' includes the @autoid annotations which can optionally specify a HASH as in @autoid(HASH).

To be useful this must be augmented with the @hashid("MyString") annotation that allows an ID to be explicitly assigned by computing the hash of a string using the same algorithm that @autoid(HASH) uses.

ptc/19-07-02 section 7.2.4.2.1 defines the mapping of sequences of basic and non basic types in terms of Java interfaces.
However, the classes implementing the interfaces are not defined.
The implementation classes are required for actual programming.
If it is intended that the user shall provide own implementations then this should be expressly stated.

7.4.15.4.2 on p.101 contains the rule

(225) <annotation_appl> ::= "@" <scoped_name> [ "(" <annotation_appl_params> ")" ]

The nature of the EBNF notation leaves room for interpreting that between the @ and the <scoped_name> there could appear spaces, tabs, or even comments.

On the other hand, 7.4.15.4.1 on p.100 contains:

(220) <annotation_header> ::= "@annotation" <identifier>

Here, it is clear that @annotation shall be treated as a single token without intermittent characters between @ and annotation.

I propose adding a clarification in the explanations at the beginning of p.102 (following rule 227):

Applying an annotation consists in prefixing the element under annotation with:

• The annotation name ( <scoped_name> ) prefixed with the at symbol( @ ), also known as commercial at. There shall be no intermittent spaces, tabs, or comments between @ and <scoped_name>.

The last sentence is my proposed addition.

Table 7-13 (Integer types) should have a little bit wider column 1 and the font size "See Building Block Extended Data" should match the other font in this table

Extend the grammar for Constants to allow constants for all Core Data Types that are currently not allowed:

• sequence
• structure
• union
• array

Section 7.4.1.4.4.4.4 Constructed Recursive Types and Forward Declarations (in the Core Data Types BB) has special semantic rules for sequences. The intent of Maps (in the Extended Data Types BB) seems to be that maps should have these same semantic rules.

There are a lot of more possibilities to be used with C++11 compared to C++, there is a specific OMG language mapping for C++11, so we would like to propose to add c++11 as defined value

Currently when we want to declare a type in a deeply nested module we have to start with all higher level modules, for example

module A {
module B {
module C

7.3 Any says:

"The IDL any type shall be mapped to org.omg.type.Any type."

A.1.4 Any says:

"The IDL type any maps to a public class named org.omg.CORBA.Any with the following definition

package org.omg.CORBA;
public class Any {
..."

Suggested solution:

Replace class declaration with:

"package org.omg.CORBA;
public class Any implements org.omg.type.Any {
..."

IDL 4.0 contained specific grammar rules for where annotations can be applied. Issue IDL41-9 revised these rules and left the spec with the general statement that (7.4.15.4.2): "An annotation may be applied to any IDL constructs or sub-constructs."

This is problematic for the following reasons:

• The phrase "under annotation" is used in multiple places in the spec without it being defined
• Tool implementors using a grammar based on the one in the spec need to make their own enhanced grammar to include <annotation_appl>, which undermines the usefulness of having a grammar in the spec
• Documentation of specific annotations (whether standardized in IDL, standardized in other OMG documents such as XTYPES, or non-standard) has no systemic way of describing where the annotation should be used
• Users have little assurance that their IDL will be understood by all conforming tools, even when using standardized annotations

IDL 4.2 section 7.4.1.4.3 Constants consistency rules on page 32 contains

• An octet constant can be defined using an integer literal or an integer constant expression but values outside the range 0…255 shall be treated as an error.

ptc/20-05-17 section 7.2.4.1.6 maps IDL octet to Java byte.
For mapping IDL const octet values 128 to 255 to Java, it should be permissible to apply promote_integer_width to octet.

This should be changed to a "may" or a "could". Shall seems overly prescriptive.

How could a compliant implementation of Equals<T> be distinguished from Equals(Object) from the callers/users perspective?

The annotations should be covered in a separate section of the document and NOT be part of a clean, canonical example.

Suggest:
// IDL
enum E

;

// C#
public enum E

;

Also should enums inherit uint?

Anonymous types should be moved to their own section

Suggest:

//IDL
typedef long myLongArray[2][3];

// C# example

Since IDL is a specification language why have an IDL interface that cannot define data types it wishes to encapsulate and use as parameters for methods and attribute types? It looks like someone had a programming language in mind. I guess in the end the reason I think basic interfaces are a bad idea is that they can only be identified heuristically. The absence of contained types is a poor indicator of the IDL authors intent regarding whether the interface is basic or not.

Currently the specification says: Note – The default value (TRUE) is significant when the annotation is present (this means that using the compact form @nested will set the element as nested, which is what is expected intuitively). It does not mean that by default (i.e.,when no annotation is present) an element is nested.

The case when no nested is present should be specified, it should be the same as TRUE or FALSE and not left open. We observed that different DDS vendors take different decisions making portability of user IDL which uses partly @nested broken. Some vendors assume default nested TRUE, others FALSE which in practice means when the user wants portable IDL he has to specify it which each IDL type.

Suggestion is to have one section or appendix where possible naming mappings could be covered.

Change the IDL example naming to match the C# community expectations if that makes it easier to specify

Beside basic types no other canonical example is included. I suggest removing the basic types and having one example.

// IDL
struct foo

;

Something like this.

Types such as sbyte and int32 are included in this section and should not be.

These types should be moved to the extended types section.

The section for these types is missing from the document.

For the CORBA specifications as part of the scope chapter there are no hyperlinks, these should be added

The specification just lists any as value for the min/max/default annotations, but that tells nothing about what is allowed as value, are for what about hex/octet values, floats, etc. Maybe make this more precise by referring to the value_expression rules `<const_expr>` as specified in 7.4.1.4.3 constants

The specification is unclear of what the user can expect when using mutable and annotations like range, what when the old version of the type has a range of 1-10 and the new one range of 1-5. An old version is send with value 6, what does the receiver get? Very likely more annotations need to be extended in their description related to mutable

extensibility is heavily under specified in IDL4.2. It is listed as a general purpose annotation but it says nothing at the moment for the case appendable/mutable is specified and types are evolved. What are at that moment the rules for assignability/compatibility. Someone who just looks at IDL4 lacks a lot of required information

This building block section is missing (e.g. sbyte).

It seems every section has this deviation of alternative identifier mappings. I find that it maps the document more difficult to read. The document at large should provide canonical text and examples. These alternatives should be placed in a section that caters to those alternatives with easy links to this section elsewhere in the document.

I could not find a place that discussed what is expected if an IDL compiler encounters an annotation that it can parse but does not understand.

The section on annotations should contain examples of how to use the various standard annotations.

This section needs to be filled out with examples of anonymous IDL types.

The example uses annotation to define the type. The mapping should be clean/pure without annotations. The annotation should be moved to the sections on annotations.
// IDL
enum AnEnum

;

// Java
public enum AnEnum {
X,
Y;
private int value;
private AnEnum(int value)

public int getValue()

public static AnEnum valueOf(int v)

7.17 Standardized Annotations
}

Same as the description

Ensure the correct separation of building block basic types (e.g. sbye)

There needs to be a section on IDL interfaces being mapped to Java 8 interfaces which provide the capability to be a proper container. This removes the need for the old fooPackage id foo were defined in an IDL interface named foo.

Now that IDL is modular with building blocks, IDL authors need a way of guarding IDL files so they are compatible with tools that implement different subsets of the building blocks. See discussion in IDL43-21 for a motivating example.

See C++ feature test macros for a possible implementation pattern.
https://en.cppreference.com/w/cpp/feature_test

Another option is to have an "IDL_VERSION" macro that can be used as a pre-processor condition.

At present, annotation syntax must be placed in the IDL file, usually right before or after the syntax being annotated.

This works very well for annotations that define shared interface constraints. It does not work well for annotations that control internal implementation details, such as the selection of an API option. These internal details should be separated from the shared interface and so do not belong in the shared IDL file.

This proposal is to add a new syntax for annotating IDL structures. The basic idea is to define an annotation that takes two parameters, a "place" in the IDL and an annotation, and has the effect of inserting the annotation at the given place. For example @insert(Foo.x, @some(value)) would be equivalent to placing @some(value) by the definition of Foo.x.

With this mechanism, end users could create a custom IDL that includes the shared IDL and then adds the custom annotations.

7.4.13.4 "Explanations and Semantics" gives a synoptic list of the complements,

Those complements are:

• Additions to structure definition in order to support single inheritance and void content (no members).
• Ability to discriminate a union with other types (wide char and octet).
• An additional template type (maps).
• Additional constructed types (bitsets and bitmasks).

The complement "Integers restricted to holding 8 bits of information" (7.4.13.4.4) should be added there.

Predecessor: CPP1116-3

For mapping the switch of unions, the language mappings choose different fixed names.
It would be desirable to permit names that reflect the user's application domain.
Example:

  enum environment_t { air, water, land };

  @switchname("environment")
  union env_info_t switch (environment_t) {
    case air:
      air_info_t air_info;
    case water:
      [...]
  };

The @switchname annotation would cause the discriminator to be mapped using the given name.

This may replace the name chosen by the language mapping (such as in the Ada mapping), or it may supplement the mapping chosen name (such as in the C++ mapping), depending on the nature of the mapped union.

The provided name may not overlap with an enum value given in a case and it may also not overlap with a branch member name.

Currently the spec says:

The << binary operator indicates that the value of the left operand shall be shifted left the number of bits specified by the right operand, with 0 fill for the vacated bits. The right operand shall be in the range 0 <= right operand < 64.•The >> binary operator indicates that the value of the left operand shall be shifted right the number of bits specified by the right operand, with 0 fill for the vacated bits. The right operand shall be in the range 0 <= right operand < 64

But this should be more restricted, the range should be dependent on the number of bits of the underlying type, when it is for example a 32bit long, the operand should be in the range of 0 <= 32

IDL 4.2 allows the @value on an enum to set a specific value for example

enum Test_E

;

It would be more clear and logical when IDL would allow

enum Test_E

;

The section that describes the default value does not include a discussion
of what to do when a default is not present. In this case a method called _default or
__default should be defined to set the discriminant to a non-switched field value.
This should be fixed before December.

The generated code for classes and structs should be allowed to override common functions such as GetHashCode and ToString.

It should also be allowed to implement additional interfaces in addition to IEquatable (see IDL4CSP-1).

It should also be allowed to add additional methods, such as Clone or copy constructors.

Allow adding additional methods and interfaces in generated types

This resolution adds explicit phrasing that allows vendors to add additional methods and interfaces to generated types.

The resolution of this issue shall be applied after the resolution of IDL4CSP-2.

All constructed data types should implement IEquatable:

The example in section 7.2.4.3.1 would now look as follows:

public class MyStruct : IEquatable<MyStruct> {
    public MyStruct() {...}
    public MyStruct(int a_long, short a_short, int[] a_long_array) {...} 
    public int a_long { get; set; }
    public short a_short { get; set; }
    public int[] a_long_array { get; set; }

    public bool Equals(MyStruct other)
        => a_long == other.a_long 
             && a_short == other.a_short 
             && a_long_array.Equals(other.a_long_array)
}

Add IEquatable interface to all generated classes

This resoultion mandates the implementation of the IEquatable interface in all generated classes.

The spec indicates that all members of a class or struct are mapped to read-write properties, as shown in 7.2.4.3.1:

public int a_long { get; set; }
public short a_short { get; set; }
public int[] a_long_array { get; set; }

However sequence members (IList) should map to read-only properties.

public IList<int> a_long_sequence { get; }

Rationale: C# best practices recommend this change: https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2227?view=vs-2019

For example, a vendor may decide to use an implementation of IList that allows accessing the memory directly (via unsafe code or Span) to optimize its serialization. If end users are allowed to completely replace the list, they may inadvertently provide a different IList| implementation that the vendor code can't serialize optimally or can't handle at all.

The same could apply to Maps.

Making sequence members read-only properties

This resolution transforms properties resulting from mapping IDL sequence and maps struct members into read-only properties, following the C# best practices described in the issue.

It also introduces setters for Unions, where setting a sequence or a map would need to also update the discriminator value.

Sequences are currently mapped to System.Collections.IList<T>, which enables vendors to roll out their own sequence implementation while maintaining compatibility with other list implementations users may use in application code. Unfortunately, unlike the interfaces we chose in language mappings like Java, IList lacks support for mechanisms to handle the internal sequence that are important to implement certain patterns. For example, IList lacks methods like AddRange(), which are necessary to implement patterns to repopulate a collections (see https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2227?view=vs-2019 and IDL4CSP-1).

As discussed in the IDL WG at the September meeting, it would be desirable to map Sequences to an Omg.Types.ISequence<T> interface that extends System.Collections.Generic.IList<T> and adds all the properties and methods in the System.Collections.Generlic.List<T> class.

Define a more complete interface for Sequence Types

This resolution introduces Omg.Types.ISequence, an interface to represent sequence types that is more complete than the generic System.Collections.Generic.IList<T>.

Omg.Types.ISequence provides the same methods and constructors as the standard C# System.Collections.Generic.List<T>.

The resolution of this issue requires applying the resolution of IDL4CSP-1 first.

The current version of the specification does not specify whether copy constructors and all value constructors do deep copies or shallow copies. The specification should indicate what's expected from an implementation to avoid problems. such as those highlighted here.

Introduce Clarifications about Copying Behavior in Constructors and Setters

This resolution clarifies the copy behavior (whether shallow or deep copies must be performed) in constructors and setters. Also, it clarifies how the @external annotations affects such behavior.

This resolution shall be applied after applying the changes introduced in the resolution of IDL4CSP-1.

In Section 7.2.3.1 "Alternative Mapping", there's a double public in the second paragraph that should be removed: "... the public public partial class shall..."

Table 7.1 lists the use of the dynamic type, which was part of the original draft but is no longer part of the IDL to C# mapping. Therefore, the row referencing dynamic should be removed.

The mapping of constants in Section 8.1.2 constants_container Parameter does not match to the mappings defined in Section 7.2.3

Fix typos and inconsistencies

This resolution addresses all reported typos and inconsistencies.

The proposed conflict resolution rules for union members called Discriminator, which prepend an '@' in front of union member named Discriminator, are invalid. The '@' can only be applied to names that conflict with C# keywords (see https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/identifier-names).

Add conflict resolution rules for conflicts with identifiers that are not C# keywords

Currently the specification only defines conflict resolution rules for names that conflict with C# keywords. This resolution introduces a rule to resolve conflicts with names that are not C# keywords.

The resolution also provides a valid solution to resolve name clashes with the property representing the union discriminator that is consistent with the IDL4 to Java Language Mapping.

Input interface arguments shouldn't have the "in" modifier.

Fix mapping of in arguments in interface methods

As reported in the issue, the mapping of in arguments in interface methods is incorrect. In this resolution, we change the mapping of in arguments so they're mapped to parameters without a modifier.