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

General consensus is to maintain the current mapping

The general consensus is to maintain CORBA::Int8 and CORBA::UInt8 for mapping the int8 and uint8 types, instead of renaming them to CORBA::TinyShort and CORBA::UnsignedTinyShort.

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.

Mapping Bitmasks to structs containing an enum and several operators

As suggested in the issue, mapping bitmasks to structs containing the former enum and several operators improves the usability of the mapped type.

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

Add additional constructors and accessors to alternative mapping for structs

Clause 8.1.1 provides an alternative mapping for structs using the @cpp_annotation and setting struct_mapping to CLASS_WITH_PUBLIC_ACCESSORS_AND_MODIFIERS. In this resolution, we provide extra constructors and accessor methods for usability purposes.

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.

IDL4 specifies the default size for Bitmasks

Clause 7.4.13.4.3.3 of IDL 4.2 states that "By default, the size of a bit mask is 32." Therefore, if @bit_bound is unspecified, we should assume the underlying type is uint32_t. It also states that "Two annotations can be used to amend a bit mask definition:" @bit_bound and @position. While an explicit @bit_bound would change the size of the bit mask, as stated in IDL 4.2, "Possible positions range from 0, which corresponds to the less significant bit, up to (size – 1), which corresponds to the most significant one." Because this specification specifies the mapping for all possible values of @bit_bound, there is no need to specify the underlying type for the default as it is 32 per IDL 4.2.

Future versions of this specification or IDL RTFs may include further clarifications to facilitate the understanding of default behaviors.

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) {}

Clarify that omg::types::bounded_<type><N> shall always be defined for potential trait specializations

With this resolution, the specification makes it clear that implementers shall always define omg::types::bounded_string<N> for potential use of trait specializations.

Future versions of this spec may explore different avenues for mapping bounded strings.

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?

*Add requirement for implementation of what() method in exceptions *

Specify that the mapped Exception class shall implement the virtual what() method declared by std::exception, which the mapped Exception inherits from, and at a minimum provide a mechanism to provide such explanatory information in the explicit constructor that provides a mechanism to set the value of all exception members.

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

Fix typos identified in this issue

This issue addressed all reported typos.

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

Add bit_bound and underlying_type traits to enums

This issue adds the bit_bound and underlying_type traits to enums consistently to the traits we have added to bitmasks.

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

No longer an issue with resolution of IDL4CPP-11

Per the resolution of IDL4CPP-11, Bitmasks no longer result on built-in types or enums, so the rules for the rest of types apply.

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

@default on string and wstring are allowed

While there is no example indicating how to use @default with strings or wstrings, there's nothing in the IDL4 specification or its C++ language mapping that prevents its use. No changes in the spec are necessary.

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:

Add omg::types::arrays for consistency

This issue adds the definition of omg::types::arrays, for consistency with other types that are mapped to either std:: equivalents or omg::types.

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;

Constants declared in the context of an interface shall be marked as static

To avoid build errors, constants declared in the context of an interface (full) shall be mapped to static constexpr.

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

Change bitset inheritance behavior

This issue replaces the inheritance behavior for bitsets, which was based on adding inherited members to the struct, to a C++ inheritance scheme.

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)

Remove is_bounded and bound traits from the list of common type traits

This resolution removes is_bounded and bound traits from the list of common type traits, as they only applied to types that can may have bounds, such as strings, sequences, or maps.

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

This issue shall be addressed in IDL 4.3 RTF

We have filed IDL43-93 to address this issue in the IDL 4.3 RTF. The IDL to C++ Language Mapping specification does not need to define the syntax or scope of @value at this moment.

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

Add extra restriction to the mapping of @external

For consistency purposes, this resolution adds an extra restriction to the mapping of @external.

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

Enum prefixes and postfixes prevent conflicts with external C++ code

In C++ 98, the mapping of IDL enums does not prevent conflicts of IDL-defined literals with the C++ code a user might be mixing or linking against. That's why even though the IDL grammar does not allow conflicts in literals within the same IDL code (such conflicts are illegal in IDL), an end user might have conflicts in the generated code, which can only be prevented adding prefix or postfix enum literal names. Mapping enums to enum classes does address this issue, but such functionality is unavailable in C++ 98.

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

Fix mapping of VT1 in example mapping of Clause 7.6 "Value Types"

The C++ mapping for VT1 in Clause 7.6 contains a number of errors, this resolution addresses such errors providing the correct code snippet.

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

Question has been addressed in Jira Issue

There is nothing to change in the specification. Future versions of the specification could add further instructions on how to deal with various implementations of omg::types::strings.

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

Fix indentation of protected and replace use of std::string with omg::types::string

This issue fixes the indentation of protected and replaces the use of std::string with omg::types::string in clause A.1.10.2.

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

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

Issue to be addressed in IDL 4.3 RTF

This issue refers to the IDL grammar, rather than the language mapping. Therefore, it will be addressed in the IDL 4.3 RTF.

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

Fix mapping of VT2 in Clause 7.6 "Value Types"

Clause 7.6 "Value Types" contains a typo in the mapping of a long, this issue fixed the typo mapping the IDL long to int32_t instead of int16_t.

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

Fix mapping of naming data types in C.2.1.2.4

In clause C.2.1.2.4, IDL struct MyType is mapped to a class, instead of a struct, which is the correct mapping. This issue addresses that mistake.

The section is silent on maps.

Refer to Maps in clause A.1.2.4

Clause A.1.2.4, which addresses the exception type for bounded types shall refer to strings, wstrings, sequences, and 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:

Fix broken cross references

The specification includes a number of broken cross references. This issue replaces broken cross references with the appropriate sections.

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.

Type traits may be inherited

Type traits may be inherited, and it is indeed a common practice, so the mapping should remain as is. The restriction would be to inheritance of classes that have a state, such as std::vector or std::string.

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

Renaming Fixed to fixed for consistency purposes

This specification defines common C++ types using lowercase names, such as bounded_string, bounded_sequence, etc. Therefore, for consistency purposes, the Fixed class shall be renamed to fixed.

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

Fix example mapping of attribute in Interfaces - Full

The example for Interfaces - Full contains an error in the mapped name of an attribute.

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

Replace use of C++ long in example code with int32_t

IDL longs are mapped to C++ int32_t, the example in clause 7.2.4.6 makes the mistake of mapping a typedef long to a using of long instead of int32_t.

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.

Update mapping of a_short in example code

Accessors for members of the union for which the mapped type results in primitive types and enums shall return by value. Therefore, the updated example reflects that:

// ...
void a_long(int32_t value) {...}
int32_t a_long() const {...}
// ...

The updated example also includes members that result in non-primitive types like strings or structs.

As part of the resolution of this issue we also provide a method to set the discriminator to a specific legal value when the union definition has an implicit default member (the current mapping only provides a _default() that sets the discriminator to a legal default value).

We also mandate that non-primitive members provide two getters:

const Foo& a_foo() const {}
Foo& a_foo() {}

and primitive members the following two getters:

int16_t a_long() const {}
int16_t& a_long() {}

If the getter selects a branch that does not match the discriminator value, the getter should throw an error.

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

Convert virtual destructors in overrides

To resolve this issue, all virtual destructors are converted to overrides.

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

Specify that middleware implementations may mandate specific bound checking mechanisms

This issue tries to convey that middleware implementations may introduce more explicit bound checking mechanisms.

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.

Issue to be addressed in IDL4.

This issue should be addressed in the IDL 4.3 RTF.

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.

Add a note to clause 7.15 to illustrate type traits for anonymous types

This resolution adds an example that shows how to aquire acquire the declared type of a struct member and use it in a traits declaration.

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

IDL Language Mappings Should Not Impose Bound Limits

Limits on bound sizes are imposed by the serialization format of middleware such as CORBA and DDS (e.g., CORBA specifies the behavior for the serialization for sequences bigger than uint32_t, and that should be enough for the middleware implementer). IDL and the corresponding IDL language mappings need not impose such limits.

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.

This issue will be addressed in IDL4CPP-11

The resolution of this issue will be addressed in IDL4CPP-11.

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

Fix @range example

This issue fixes the use of @range in the examples.

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?

Middleware Implementations Should Deal with Conversions

Solving conversion issues would be a task for the specific middleware implementation. If the mapping were to use char*, implementers would have to deal with the same issue.

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

This issue is referring to a different specification

This issue is actually pointing to the IDL to C++11 specification.

For instance is this legal:

struct S

;

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

Issue Refers to IDL Grammar

This issue will be addressed in the IDL 4.3 RTF, as it refers to the IDL grammar rather than the language mapping.

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

This issue belongs in the IDL4 RTF.

This issue should be addressed in IDL4.

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

Error handling and exceptions will be treated in feature versions of the spec

By design, the current version of this specification does not specify explicit mechanisms to report errors (e.g., which exception should be thrown or whether exceptions should be thrown at all). The intention was to be able to support both environments where exceptions are valid and are allowed, as well as environments where applications may not throw or handle exceptions.

Future versions of this specification may define explicit mechanisms to report errors, and will aim to harmonize them across middleware implementations.

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

Defer the resolution of this issue to the resolution of the related IDL RTF issue

This issue is deferred until the resolution IDL43-94.

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.

Example Transformations To Be Incoporated in Future Versions of the Standard

We think this is an interesting concept, but it hasn't been addressed in the existing IDL4 to Language Mappings. To better align version 1.0 with the existing mappings, we think this proposal should be addressed in subsequent RTFs.

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

Passing shared_ptr by value could introduce certain issues

If we pass by value we could introduce certain issues, like locking (having to increase the reference counter). It's unclear to us whether this would be beneficial. If we pass it by const reference, we're guaranteeing that the object won't be destroyed until the end of the function.

After a discussion within the IDL WG, we agreed on leaving the mapping as it currently is and reevaluate improvements to the mapping in future RTFs.

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?

Defer until the resolution of the related IDL RTF issue

The IDL RTF must address some of the underlying issues when applying @min, @max, @range, and @default annotations (e.g., see IDL43-89). Therefore, we are deferring the implementation of an updated mapping until the IDL RTF tackles the underlying issue.

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

Defer to future versions of this specification

Future versions of this specification may remove Clause D.3 or replace its content with pointers to the appropriate clauses in the IDL to C++11 v1.7 specification. However, because this specification originally targeted v1.6 of such specification, it will require some research and agreement on the best path forward within the MARS IDL WG.

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

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

MyTemplate<double, 5.0> x;

Mapping for min, max, and ranged remains the same

In this case, an alternative implementation would introduce too much complexity. For that reason, we propose to defer this issue to future RTFs. State of the art compilers supporting C++20 work with the proposed mapping. Future RTFs may add additional information for implementers that require compatibility with earlier compilers.

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

List of Valid Key Types for Maps Will Be Provided in IDL 4.3

This issue is tightly coupled with IDL43-70, which aims to determine the list of valid key types for IDL maps. Because the current IDL4 to C++ Language mapping targets IDL 4.2 (which does not specify the list of valid types), this FTF will no't be adding further restrictions.

Future versions of the IDL4 to C++ Language mapping may add key map type restrictions compliant with the resolution of IDL43-70.

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

Defer to future revisions of the specification

In this case, we chose to use {} only when necessary, and use = instead for when both options were possible. Having said that, given the current trend leaning towards the use of {}, future versions of this specification may change this coding convention.

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

C++20 Modules to be explored in future RTFs

The use of C++20 modules will be explored in future versions of this specification.

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.

The @csharp_mapping annotation introduced in Clause 8.1 provides an argument to select the alternative constants mapping and provide a name for the class that scopes a group of contants. However, there current syntax does not allow indicating that mapped constants shall be mapped as standalone classes, which is the other mapping option. Perhaps, we could give a name for the mapping that maps constants to standalone classes, and map that to setting constants_container to an empty string.

As a side issue with constants, in both mappings the classes that contain the constants are not static. This may confusing as you could create instances of a class that only has constants, which are static. Perhaps, the "Standalone Constants Mapping" should create classes that are "public static" (which are also sealed), and the alternative mapping should create "public static partial" classes.

Extend constants_container parameter of @csharp_mapping to specify how to map to standalone classes and convert classes containng constants to static classes

This resolution provides names for the two mapping options for constants and specifies how to select each of them using the @csharp_mapping annotation. It also converts the classes that wrap constants in both mapping options into "static classes".

The resolution to this issue must be applied after the resolution of IDL4CSP-4.

Predecessor: https://issues.omg.org/browse/I2JAV13-11

Many of the IDL to Java translators support an option to specify a Java package prefix for the generated code (e.g. Oracle idlj option -pkgPrefix; JacORB option -i2jpackage; rtiddsgen option -package).
This is not exactly equivalent to hard coding the prefix as modules in the IDL: When using the translator option, other language mappings do not see the prefix.

The package prefix provided to the IDL translator may produce a conflict with names in the IDL file.
Example:

// file: test.idl
module test {

   enum com_t { zero, one };

   struct org_t {
      short foo;
   };

   typedef string<16> net_t;

   struct structure {
      com_t com;   // "com" is in conflict when providing prefix option such as: com.acme
      org_t org;   // "org" is in conflict when providing prefix option such as: org.acme
      net_t net;   // "net" is in conflict when providing prefix option such as: net.acme
   };

};

Notice that the Java generated for this IDL does not compile but it does compile for other languages (C++, Ada, etc).

Section 7.1.1.1 (Name Transformation Rules) contains:

If the mapped name or identifier collides with a reserved name in 7.1.2, the collision is resolved by prepending an underscore ("_") to the mapped name.

I suggest adding a further sentence:

This also applies to name collisions caused by a Java package prefix specified at the IDL to Java translator.

Document conflict resolution rules for compiler and vendor-extension settings

Many IDL to Java translators provide extensions to introduce package prefixes for the generated code. Even though these rules are out of the scope of this specification, in this resolution we add a note indicating that name resolution rules may be also applied to collisions caused by these settings.

The constant mapping is prone to namespace collision

Restructure Constants Mapping to Address all Possible Use Cases

With this resolution, we introduce a new default mapping for constants that addresses all possible scenarios. The previous mapping, which provided a simpler but partial solution, is now an optional mapping that can be exercised with the @java_mapping annotation.

NOTE—The example code in the revised text takes into account the names and conventions introduced in the resolution of IDL4JAV-4. For simplicity, the resolution of IDL4JAV-4, which edits all code snippets in the document, applies the new default mapping of constants throughout the document.

This issue is a placeholder for any feature request in terms of namespace prefix flexibility, compatibility with CORBA IDL, or possible additions to the java mapping annotation to adjust the language mapping.

This issue should be closed with no change if no such features or concerned are filed.

No extra functionality was formally requested as part of FTF

This placeholder issue was not used to suggest any extra functionality or flexibility in the language mappings. Therefore, we close it with no changes.

In the future, issues like this should only be created if there's an actual request or concern.

Section 7.1.1.1 provides ambiguous guidance on name mapping from IDL to Java 8.

We should adopt the solution agreed upon for the IDL to C# Language Mapping.

On a side note, many Java snippets use semicolons at the end of a class declaration, which is unnecessary in Java.

Introduce IDL Naming Scheme and Java Naming Schemes

To address this issue, we are adopting the approach we followed in the IDL to C# Language Mapping specification. In a nutshell, we introduce two naming schemes that can be applied when IDL transforming type identifiers and names to Java.

For example, these building blocks, etc:

• CORBA specific interfaces
• "Any" type
• CORBA specific value-type
• System Exception
• Pseudo Objects [may remove]
• org.omg package

Define CORBA-Specific Mappings to CORBA in Annex A

This issue adds all the required CORBA-specific mappings to Annex A.1: CORBA-Specific Mappings. It includes a CORBA-specific mapping for Exceptions, TypeCode, Object, Any, Interfaces, and Value Types. The rest of mappings are derived from applying the generic IDL to Java mapping rules specified throughout the document.

The resolution of this issue takes into account the changes introduced with IDL4JAV-4 to provide an IDL Naming Scheme and a Java Naming Scheme.

The revised submission contains a number of typos and inconsistencies that should be fixed:

• In Clause 7.2.4.2.1.1, Sequence of Basic Types, IntarfaceName should be InterfaceName.

• In Clause 7.2.4.2.1.2, Sequence of non Basic Types, the text describing when to throw an exception is somewhat repetitive.

• In Clause 7.2.4.3.2 Unions, the requirement for implementing java.io.Serializable is repeated.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

In section 7.2.4.2.1.1 on page 13 top of page after end of fixed font Java code:

Where:
• <IntarfaceName> is the interface name indicated in Table 7.4.

<IntarfaceName> should be <InterfaceName>

In Clause 7.2.4.2.1.2, Sequence of non Basic Types, the text describing when to throw an exception is somewhat repetitive.

In Clause 7.2.4.3.2 Unions, the requirement for implementing java.io.Serializable is repeated.

In section 7.2.4.3.2 on page 16 paragraph before the union U1 example:

[...] The first modifier method shall
take no arguments, return void, and setsthe discriminant to the first available default value starting from a 0 index of the
discriminant type.

setsthe should be set the.

In section 8.1.3 table 8.2 column "IDL Construct", repeated typo:
Accesor should be Accessor.
In particular, on page 32:

Structure Member Name in
Accesor/Modifier Methods

Union Member Name in
Accesor/Modifier Methods

and on page 33:

Interface Attribute Name in
Accesor/Modifier Methods

Exception Member Name in
Accesor/Modifier Methods

Bitfield Name in Bitset
Accesor/Modifier Methods

Throughout the document URIs starting with "http://" should start with "https://" instead.

This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

The specification should allow application of annotations to:
declarations, members, function parameters, union discriminator, enumerator literals, typedefs, sequence parameter, array parameter.

Some examples:

struct SS {
    @MemberAnnotation(value)  MyType  m1;
};

emum EE {
    @Value(value)  Enum1;
};

union MyUnion switch ( @key long ) {
   case 1:
       @CaseMemberAnn MT1 m1;
   defalt:
       long l;
};
struct SS {
    @shared sequence< MyType, 3>   m1;
    sequence<@shared  MyType, 3>   m1;

    @shared MyType m1[3];
    MyType @shared m1[3];

    @shared MyMatrix mm[3][4];
    MyMatrix @shared mm[3][4];
};


typedef MyType @shared MyTypeArray3[3];
typedef @shared MyType MyTypeArray3[3];

Clarify application rules for annotations

An annotation can be placed on any IDL constructs or sub-constructs.
Stating that in the grammar rules complicates dramatically all the rules and creates a dependency issue between building-blocks.
The proposed solution is therefore:

1. to remove from the grammar any reference towards where annotations can be placed – cf. rule (202), as it wrongly gave the impression that annotations could only be placed on first-level definitions.
2. to state more clearly in the text that annotations can be placed on any IDL constructs and sub-constructs.

(Note that the format for applying annotation remains defined by EBNF rules as it was).

The IDL specification uses the term "simple template types" to refer to string, sequence, map, and fixed-point types. The reason being because they can be parameterized by the type of the element and/or length.

The first problem is that there are no "complex template types" anywhere in the spec so this "simple" term is confusing.

In addition to this, section 7.4.1.4.4.1 (Simple Types) provides the following definition:

Simple types are types whose definition more or less pre-exists to any IDL specification. They can be split in two categories:
• Basic types that basically represent numbers and characters and fully pre-exist any IDL specification.
• Simple template types whose generic definition pre-exists any IDL specification but need to be instantiated with parameters, to become actual types.

But later on it includes "sequences" as one of the "simple template types" . This may be OK for strings and fixed-point types as they are parameterized with just integer "lengths", or even sequences of primitive types. However this is not correct because soem sequences require prior definition of the underlying element type thus do not "pre-exists to any IDL specification".

Section 7.4.1.4.4.1.2 (Simple Template Types) provides the following definition:

Simple template types are template types whose generic definition pre-exists any IDL specification. To be used as an actual type, such a generic definition must be instantiated, i.e., given configuration parameters, whose nature depends on the template type.

Note that the categories "Simple Types" and "Simple Template Types" were introduced in IDL4. It was not present in IDL 3.5 and earlier.

These issues should be resolved.

Reorganize section 7.4.1.4.4.1 and provide more accurate definitions

Section 7.4.1.4.4.1 is not about declaring types but referencing types so it should be renamed to something like "Referencing Types" and the description changed accordingly. It should also be moved to be before 7.4.1.4.4 (Data Types).

The current subsections 7.4.1.4.4.1.1 (Basic Types ) and 7.4.1.4.4.1.2 (Simple Template Types) should be moved out to the same level.

The section "Simple Template Types" should e renamed "Template Types" and references to "simple template types" changed to "template types"

The definition of "template types" should be improved.

IDL uses the keywords short, long, and long long to designate integer types of sizes 16, 32, and 64 bits, respectively.

In IDL the size of these integer types is well specified. However these names confuse users familiar with languages such as C and C++ where the size of these integers is platform specific. As a result many users end-up defining their own typedefs for different size integers (e.g. INT16, or Int16) resulting in IDLs that are non-uniform do not leverage the built-in types.

To avoid this, IDL should follow the approach taken in C/C++ and introduce typedefs whose name unambiguously indicates the size of the representation.

Proposed "builtin typedefs" would be:

typedef               short              int16; 
typedef               unsigned short     uint16;
typedef               long               int32;
typedef               unsigned long      uint32;
typedef               long long          int64;
typedef               unsigned long long uint64;

Add new keywords for the integer types

Add new keywords for int16, int32, int64, uint16, uint32, and uint64. This should go in the "Building Block Extended Data Types" so that it does not impact existing applications.

The content "Scope" section appears to have been copied from the original RFC motivation. As a result it reads more as a "history" of the specification rather than defining the scope.

The history of how the specification came about is useful and should be stated somewhere. However the main focus of the scope section would be to define the boundaries and goals for the specification.

Rewrite Scope and move historical background text to section 6

Most of the current text in Section 1 "Scope" is about the history of the specification. This text should be moved to section 6 "Additional Information"

A paragraph describing the goals and boundaries for the IDL specification should be written and placed in section 1. "Scope"

The building blocks BB Templates, BB Annotations, BB Anonymous Types, and BB Extended Types are both basic (dealing just with data types) and general purpose (independent of platform CORBA, DDS, CCM).

They also have no dependencies on other building blocks other than the BB Core Data Types. Even if the BB Interfaces does not depend on them (i.e. some specification can comply with the BB Interfaces without complying wth the aforementioned modules), it is still possible to define interfaces that use these type extensions and annotations.

For this reason these should me moved to appear in the specification ahead of the BB Interfaces and platform- specific BBs.

The most natural place would be following the BB Core Data Types.

Reorder Building Blocks

Reorder building blocks, as suggested in the issue description.
The Building Blocks for Extended Data Types, Anonymous Types, Annotations, and Template Modules should be placed following the Building Block for "Core Data Types".

Extensibility Annotation

Section 8.3.1.6 defines the @extensibility annotation as follows:

@annotation extensibility {
    enum ExtensibilityKind {
        FINAL,
        APPEND,
        MUTABLE
    };
    ExtensibililtyKind value;
};

However, section 7.2.3 of DDS-XTYPES specifies that the types of extensibility and mutability are the following:

• FINAL
• APPENDABLE
• MUTABLE

For consistency, the IDL specification should use "APPENDABLE" instead of "APPEND".

Shortcut Annotations

In Section 8.3.1 the IDL specification defines the annotations @final as a shorcut for @extensibility(FINAL) (Section 8.3.1.7) and @mutable as a shortcut for and @extensibility(MUTABLE) (Section 8.3.1.8).

For consistency, the IDL specification should introduce @appendable as a shortcut for @extensibility(APPENDABLE).

Default Literal Annotation

DDS-XTYPES Section 7.3.1.2.1.10 (Default Literal for Enumeration) defines the annotation @default_literal as:

@annotation default_literal {};

This is a general purpose annotation that marks an element of an enumeration as the default one for that enumeration.

For consistency with similar generic annotations it should be added to IDL section 8.3.2 (Group of Annotations Data Modeling)

Modify annotations as suggested in issue description

Perform the suggested modifications

As of version 4.1, IDL lacks explicit support for 8-bit signed/unsigned integers. While, there are two data type with 1-byte size, these are not suitable for encoding 8-bit integers:

• char => 8-bit quantity that:
  • encodes a single-byte character from any byte-oriented code set, or
  • in an array, encodes a multi-byte character from a multi-byte code set
• octet => opaque 8-bit. guaranteed not to undergo any change by the middleware.

Unfortunately, reference programming languages don't have consistent behavior:

• Java: byte => signed 8-bit
• C#
  • byte => unsigned 8-bit
  • sbyte => signed 8 bit
• C (C90 and later)
  • char => unspecified. Compiler dependent (http://www.arm.linux.org.uk/docs/faqs/signedchar.php)
  • signed char => signed 8-bit number
  • unsigned char => unsigned 8-bit number
• C++
  • char => recommended for chars only. Allowed for numbers but unspecified sign
  • signed char => signed 8-bit number
  • unsigned char => unsigned 8-bit number

Other dialects of IDL provide support for 8-bit signed/unsigned integers as follows:

• MIDL (Microsoft's IDL)
  • Introduces the small keyword to represent 8-bit integers (see MIDL documentation). Additionally, it uses the hyper keyword to represent 64-bit integers (i.e., a long long in OMG IDL).
  • The integer types in MIDL are:
    • [unsigned] small (8-bit integer)
    • [unsigned] short (16-bit integer)
    • [unsigned] long (32-bit integer)
    • [unsigned] hyper (64-bit integer)
  • This IDL dialect introduces also the signed keyword and therefore numeric values can be marked as signed or unsigned (if unspecified they default to signed).
  • Web IDL
    • Introduces byte keyword to represent a signed 8-bit integer and treats octets as an unsigned 8-bit integer (see documentation).
    • The integer types in Web IDL are:
      • byte (signed 8-bit integer)
      • octet (unsigned 8-bit integer)
      • [unsigned] short (16-bit integer)
      • [unsigned] long (32-bit integer)
      • [unsigned] long long (64-bit integer)
• XPIDL
  • Does not support signed 8-bit integers (see documentation)

Add support for 8-bit Integers

We have identified four possible candidate solutions listed below. See the end for the decision on the adopted solution.

1. Introduce a new keyword in IDL to indicate an 8-bit integer.

This would preserve the current semantic and mapping of octet (opaque, do not use it as a number). If we do this it would be like the other integers in IDL where it is signed unless we qualify it with "unsigned."

This solution has three alternatives depending on the keyword selected. We have considered byte, small, and tinyint:

Alternative 1.1: Add new byte keyword

byte  ==> signed 8-bit integer
unsigned byte  ==> unsigned 8-bit number

This approach is clean and consistent but we are concerned with using the keyword "byte" because of the ambiguity with the definitions in C# and Java. It also does not sound like a number. It sounds like "octet". In fact it means exactly that.

Alternative 1.2: Add new small keyword (following MIDL's model)

small  ==> signed 8-bit integer
unsigned small  ==> unsigned 8-bit number

Alternative 1.3: Add new tinyint keyword (following SQL model)

tinyint  ==> signed 8-bit integer
unsigned tinyint  ==> unsigned 8-bit number

*Alternative 1.4: Add new int8 and

keywords (following new C/C++ standard names)*

int8    ==> signed 8-bit integer
uint8  ==> unsigned 8-bit number

Solution 2: Use annotations on "octet" to indicate use as integer

This would mean that we could have "octet" type used three different ways:

octet                        -- current meaning (opaque 8-bit) not a number
@signed octet       -- signed 8-bit number
@unsigned octet  -- unsigned 8-bit number

This approach seems less clean than Approach 1 but it has the advantage of being less ambiguous and backwards compatible. Having said that, having both a keyword and an annotation called unsigned is a bit ambiguous. Also this would be the only use of the @unsigned annotation which is confusing. For example, someone may be tempted to use @unsigned short as a type.

Solution 3: Leverage the existing @bit_bound annotation

IDL4 says this about the @bit_bound annotation:

"it may be used to force a size, smaller than the default one to members of an enumeration or to integer elements."

So it seems if we used:

struct MyStruct {
     @bit_bound(8)  short             member1;
     @bit_bound(8)  unsigned short    member2;
};

The @bit_bound(8) would affect the serialization and also the language mapping.

For example in Java member1 could be typed as byte whereas member2 would be short in order to accommodate values between 128 and 255.

The advantage of Solution 3 is that it reuses the concepts already present without new keywords and annotations in a manner consistent with the intended purpose.

There are two alternative ways to do this:

Alternative 3.1
Just explain in the IDL 4 spec that this is the pattern used to model 8-bit integer types.

Alternative 3.2 (providing typedef for all integer types)

Expand the IDL 4 to define typedefs for all integer types making the size of the representation more obvious (similar to the new standard integer types in C99 and C++).

typedef @bit_bound(8) short              int8;
typedef @bit_bound(8) unsigned short     uint8;
typedef               short              int16; 
typedef               unsigned short     uint16;
typedef               long               int32;
typedef               unsigned long      uint32;
typedef               long long          int64;
typedef               unsigned long long uint64;

Solution 4: Allow the existing keyword "unsigned" to be used with octet

There are two alternative ways to implement this.

Alternative 4.1 Add also a signed keyword

Add signed as a keyword, which overcomes the ambiguity of solution (2). With the signed keyword, we could specify whether an octet (or a char) is signed or unsigned and follow C/C++ convention.

octet                   -- current meaning (opaque 8-bit) not a number
signed octet       -- signed 8-bit number
unsigned octet   -- unsigned 8-bit number

Alternative 4.2 Redefine “octet” to mean signed int

With this approach we would have:

Thus in C we would map IDL octet to C90 "signed char" and IDL "unsigned octet" to C90 unsigned char.

This mapping may break API portability with previous mappings, or break application code where the "char" was mapped to an unsigned value (e.g. in ARM processors).

To workaround it we could provide some way to prevent the mapping to "signed char". Maybe this is some command-line option to rtiddsgen, like "-nosignedchar"

Adopted solution

The chosen solution is 1 with alternative 4 (int8, uint8).
The reason to prefer introducing new keywords rather than relaying on annotations is that using an annotation (e.g. @bit_bound(8) opens the door for that annotation to be used in unexpected context and with un-expected parameters. For example the user could annotate not just a short, but also a long or long long. Or they could use a different value other than 8. All these cases would have to be described and handled resulting in more complexity for the user and tools. The "keyword" approach is simpler, more constrained, and better aligned with what the user expects.

The reason to choose int8 and uint8 is to align it with the resolution of IDL42-9. So we save having to add another keyword like "small
or "tiny" which would not be intuitive to the user.

Rule 174 requires a space after the open brace:
(174) > <porttype_def ::= "porttype" <identifier> "

"

This has the following consequence:
Valid:
porttype TESTPORT

;

Invalid:
porttype TESTPORT

;

I expect this was just an oversight, because it's the only instance in the grammar that requires a space after an opening curly brace.

Fix grammar for Rule 174

Perform the change suggested in the issue resolution

This issue gathers a number of typographical error and grammatical improvements that woudl enhance the readability of the specification.

In section 8.3.3 (Group of Annotations: Units and Ranges) in the declaration of struct Foo it uses the keyword "Struct". It should be "struct" instead.

Section 2 (Conformance Criteria) edit the first sentence of the first paragraph as shown below:

This document defines IDL such that it can be referenced by for other specifications to reference and . It contains no independent conformance points.

Section 2 (Conformance Criteria) edit the 3rd sentence of the first paragraph as shown below:

However, the general organization of the clauses (by means of atomic building blocks and profiles that group them as detailed afterwards) is intended to ease conformance description and scoping.

Section 2 (Conformance Criteria) edit the bullets as shown below:

1. Future specifications that use Any future specification using IDL shall reference this IDL standard or a future revision thereof.
2. Future revisions of current specifications using that use IDL may reference this IDL standard or a future revision thereof.
3. Reference to this standard must shall result in a selection of building blocks possibly complemented by groups of annotations.
a. All selected building blocks shall must be supported entirely.
b. Selected annotations shall must be either supported as described in ‎8.2.2 Rules for Using Standardized Annotations, or fully ignored. In the latter case, the IDL-dependent using specification shall not define a specific annotation, either with the same name and another meaning or with the same meaning and another name.

Section 7.1 (Overview) edit the 2rd paragraph as shown below:
OMG IDL is a language that allows unambiguously specifying unambiguous specification of the
interfaces that client objects may use and (server) object implementations provide as well as all needed related constructs such as exceptions or and data types. Data types are needed to specify parameters and return value of interfaces' operations. They can be used also as first class constructs.

Section 7.1 (Overview) edit the 3rd paragraph as shown below:
IDL is a purely descriptive language. This means that invoking operations, implementing them or creating and accessing data actual programs that use these interfaces or create the associated data-types cannot be written in IDL, but in a programming language, for which mappings from IDL constructs have been defined. The mapping of an IDL construct constructs to a programming language construct will depend on the facilities available in the that programming language. For example, an IDL exception might be mapped to a structure in a language that has no notion of exception exceptions, or to an exception in a language that does. The binding of IDL constructs to several programming languages is described in separate specifications.

In Section 7.1 (Overview) edit the 4th paragraph as shown below:
A source file containing specifications written in IDL must shall have a ".idl" extension.

In Section 7.1 (Overview) edit the 5th paragraph as shown below:
The description of IDL grammar uses a syntax notation that is similar to Extended Backus-Naur Format (EBNF). However, to allow composition of specific parts of the description, while avoiding redundancy; a specific new operator (::+) has been added. This operator allows adding alternatives to an existing definition (assuming x ::= y, x ::+ z means actually x ::= y | z). For example, assuming the rule x ::= y, the rule x :: z shall be interpreted as x ::= y | z.

In Section 7.2.6.2.1 (Wide and Non-wide Characters) modify the last sentence as shown below:
Attempts to assign a wide character literal to a non-wide character constant, or to assign a non-wide character literal to a wide character constant, shall be treated as an error result in a compile-time diagnostic.

In Section 7.2.6.2.2 (Escape Sequences to Represent Character Literals) change the two occurrences of "must" to "shall" as shown below:
Nongraphic characters shall must be represented using escape sequences as defined below in Table ‎7 9. Note that escape sequences shall must be used to represent single quote and backslash characters in character literals.

In Section 7.4.1.1 (Purpose) edit the first paragraph as shown below:

This building block constitutes the core of any IDL specialization (all other building blocks assume that this one is included). It gathers all contains the syntax rules that allow defining most data types with what allows and the syntax rules that allow IDL basic structuring (i.e., modules). and, because Since it is the only mandatory building block which is mandatory, it also contains the root nonterminal <specification> for the grammar itself.

In Section 7.4.1.4.3 (Constants) first paragraph, change "must" to "shall" as shown below.
Well-formed constants must shall follow the following rules:

In Section 7.4.1.4.3 (Constants)
Perform edits changing:
"which must" to "which shall",
"rules are applied" to "rules shall be applied",
"are applicable" to "shall be applicable",
"are evaluated" to "shall be evaluated",
"are considered" to "shall be considered",
"are not considered" to "shall not be considered",
"is considered" to "shall be considered",
"are discarded" to "shall be discarded",
"are multiplied" to "shall be multiplied",
"is divided" to "shall be divided",
"are added" to "shall be added",
"is subtracted" to "shall be subtracted",

"is not performed" to "shall not be performed"
"can combine" to "may combine",
"using the imputed type" to "based on"
"If either argument is ... use" to "If either argument is ... it shall use"
"an error shall be flagged by the compiler" "it shall be treated as an error"
"shall be flagged as a compile time error" to "shall be treated as an error"
"shall cause a compile-time error" to "shall be treated as an error"

"has no effect" to "shall have no effect"

"should be shifted" to "shall be shifted"
"should be generated" to "shall be generated"

In section 7.4.1.4.4 (Data Types) Change "can" to "may" in the first sentence as shown below:
A data type can may be either a simple type or a constructed one. Those different kinds are detailed in the following clauses.

In section 7.4.1.4.4.1 (Simple Types) replace the first bullet:
• Basic types that basically represent numbers and characters and fully pre-exist any IDL specification.
With:
• Basic types representing primitive builtin types such as numbers and characters.

In the same section replace: "Those two categories" with "These two categories"

In the same section edit 3rd paragraph as shown below
Note – Within this building block, anonymous types, that is, types actual the type resulting from an instantiation of a template type cannot be used directly as is (anonymously). Instead, prior to any use, template types must it needs to be given a name through a typedef declaration prior to any use. Therefore, as expressed in the following rules, referring to a simple type can be done either using directly its name, if it is a basic type, or using through a scoped name, in all other cases:

In section 7.4.1.4.4.1.1 (Basic Types) Edit the first paragraph as shown below:
Basic types are pre-existing types that represent numbers or characters. The set of basic types is They are defined by the following rules:

In section 7.4.1.4.4.2.4 (Constructed Recursive Types and Forward Declarations) change the 3 occurences of the sentence
Compilers shall issue a diagnostic if this rule is violated.
With:
If this rule is violated it shall be treated as an error

In section 7.4.1.4.4.4 (Native Types) modify the second paragraph as shown below:
As stated in the following rules, declaring a native type consist in just is done prefixing the type name (<simple_declarator>) with the native keyword:

In section 7.4.2.4 (Explanations and Semantics) edit the second paragraph as shown below:
An any logically contains a value and some means that specifies to specify the actual type of the value. This means However, the specific way in which the actual type is defined is middleware-specific . Each IDL language mapping provides operations that allow ‎programmers to insert and access the value contained in an any as well as the actual type of that value.‎

In section 7.4.3.4.2 (Exceptions) change "is" with "shall be" as shown below:
If an exception is returned as the outcome to an operation invocation, then the value of the exception identifier is shall be accessible to the programmer for determining which particular exception was raised.

In the same section, 3rd paragraph, change "will" with "shall be" ab "is" with "shall be" as shown below:
If an exception is declared with members, a programmer shall be will be able to access the values of those members when such an exception is raised. If no members are specified, no additional information shall be is accessible when such an exception is raised.

In the same section, last paragraph, remove the word "thereafter"

In section 7.4.3.4.3 (Interfaces) modify the last sentence of the 2nd paragraph as shown:
An interface may also be declared with no definition with using a forward declaration (<interface_forward_dcl>).

In section 7.4.3.4.3.1 (Interface Header) modify the last paragraph as shown below:
A parameter or structure member which is of an interface type is actually semantically as a reference to an object implementing that interface. Each language binding describes how the programmer must represent such interface references.

In section 7.4.3.4.3.3 (Interface Body) modify the first paragraph as shown below:
As stated in the following rules, within an interface body, can be defined operations and attributes can be defined. Those constructs are defined in the scope of the interface and exported (i.e., accessible outside the interface definition using through their name scoped by the interface name).

In section 7.4.3.4.3.3.1 (Operations) replace "must" with "shall" in:
Operations that do not return a result shall must specify void as return type.
In the same section edit the paragraph below as shown:
The absence of a raises expression on an operation implies that there are no operation-specific exceptions. Invocations of such an operation may are still liable to receive raise one of the middleware-specific standard exceptions.

In section 7.4.3.4.3.3.2 (Attributes) replace "can" with "may" in the first sentence as shown:
Attributes may can also be declared within an interface.

In the same section edit the bullet below as shown:
• For plain attributes, raises expressions allow to indicate which of the potential user-defined exceptions may be raised are when the attribute is read (getraises) and which the ones are when the attribute is written (setraises). A plain attribute may have a getraises expression, a setraises expression or both of them. In the latter case, the getraises expression must be declared in first place.

In the same section edit the paragraph below as shown:
The absence of a raises expression (raises, getraises or setraises) on an attribute implies that there are no attribute-specific exceptions. Accesses to such an attribute may are still raise liable to receive middleware-specific standard exceptions.

In section 7.4.4.4 (Explanations and Semantics) modify the 1st paragraph as shown below:
This building block adds the possibility to embed inside an interface declaration, declarations of types, constants and exceptions inside an interface declaration.

In the same section modify the paragraph as shown below:
All those elements are exported (i.e., visible under the scope of their enclosing hosting interface). In contrast As opposed to attributes and operations, they may be redefined in a derived interface, which has the following consequences:

In the same section modify the last sentence in the paragraph as shown below:
An attempt to use an ambiguous name without qualification produces a compilation shall be treated as an error.

In section 7.4.5.1 (Purpose) modify the 2nd paragraph as shown below:
In contrast As opposed to interfaces which are merely groups of operations , values carry also state contents. A value type is, in some sense, half way between a "regular" IDL interface type and a structure.

In the same section modify the second bullet as shown below:
• Supports a single Single interface support.

In section 7.4.5.4.1.3.1 (State Members) modify the last sentence in the first paragraph as shown below:
While its public part is exposed to all, the private part of the state is only accessible to the implementation code and the marshaling routines.

In section 7.4.5.4.2 (Forward Declarations) modify the first sentence in the first paragraph as shown below:
Similar to Like interfaces, value types may be forward-declared, with the following syntax:

In section 7.4.9.4 (Explanations and Semantics) change "must" to "shall" in teh first bullet as shown below:
• A home declaration must shall specify exactly one component type that it manages. Multiple homes may manage the same component type.

In section 7.4.12.1 (Purpose) modify the first paragraph as shown:
The purpose of this building block is to allow embedding constructs in template modules. Template modules may be parameterized by a variety of parameters (called formal parameters), which by transition transitively makes all the embedded constructs parameterized by the same parameters. Before using it, a template module needs to be instantiated with values suited for the formal parameters. A template module instantiation results in a de facto instantiation of all its Instantiation of the template module instantiates all the embedded constructs.

In section 7.4.15.4.1 (Defining Annotations) edit the last two notes as shown below:
Note – Annotations may be user-defined, using this syntax. They can also be implicitly defined by the IDL-processing tools a compiler. In the latter case, the behavior should be as if the related definitions were included at the beginning of the IDL specification.

Note – Annotations should not cause more compile IDL-processing errors than strictly needed. Therefore, in case of multiple definitions of the same annotation in one IDL specification , the the IDL-processing tools compiler should accept them, provided that they are consistent. In contrast, malformed definitions shall be treated as an error In return, compilers should raise an error in case of malformed definitions.

In section 7.4.15.4.2 (Applying Annotations) modify the first bullet as shown below:
• The annotation name (<scoped_name>) prefixed with the at symbol commercial at (@), also known as commercial at.

In the same section modify the second note as shown below:
Note – Annotations should not cause more compile IDL-processing errors than strictly needed. Therefore, in case an unknown annotation is encountered, it should be simply ignored by the IDL-processing tools compiler. In contrast, malformed definitions shall be treated as an error In return, compilers should raise an error in case of malformed annotations.

In section 7.5.1 (Qualified Names) modify the last paragraph as shown below:
The declaration of attribute Title in interface C is ambiguous, since the compiler IDL-processor does not know which string_t is desired. Ambiguous declarations shall be treated as yield compilation errors.

In section 8.2.2 (Rules for Using Standardized Annotations) modify the bullets as shown below:
• Shall Must respect totally the standardized annotation syntax.

• May clarify the actual meaning of the annotation in the specific targeted context. That actual meaning may be more precise than, but shall must remain compliant with, the general one expressed here.

• Shall Must indicate the default behavior when no annotation is placed on an element that may be annotated. Note that this default is never identical to not the same as the default values defined provided for the annotation members (when these default values exist). This is because as the later values are just intended to be the most logical values when the annotation is present.

Fix the typos and make the improvements suggested in the issue description.

Apply the changes suggested in the issue description.

TITLE:

The IDL4 spec syntax for bitsets departed from the one used in DDS-XTYPES.

DESCRIPTION:

In DDS XTYPES a bitset is defined like an enumeration with some extra annotations. For example:

@BitSet @BitBound(16)

     enum MyBitSet {

       FLAG_0,

       FLAG_1,

       @Value(7) FLAG_7

       @Value(15) FLAG_LAST

};

This defined the total number of bits in the bitset (16) as well provided symbolic names for the bits (FLAG_0), ... It also allowed the bit assignment to be defaulted (e.g. FLAG_0, FLAG_1) or explicitly assigned.

It is unclear how to do this in IDL4.

On the one hand one could write

struct MyBitSet {

    bitset<1> FLAG_0;

    bitset<1> FLAG_1;

    bitset<1> FLAG_7

    bitset<1> FLAG_LAST;

};

This would indicate each flag uses one bit. But it would not constrain the size of the overall bitset, nor the bit values for the flags.

One could also say:

struct MyBitSet {

    bitset<1, 16> FLAG_0;

    bitset<1, 16> FLAG_1;

    bitset<1, 16> FLAG_7

    bitset<1, 16> FLAG_LAST;

};

According to 7.2.8.6.3.2 the second integer would specify that the representation should use a 16-bit integer. But nowhere it is stated that all these will be reusing the same 16-bit integer...

Also bitsets can appear inside other structures as in (see 7.2.8.6.3.2):

struct MyStruct {

            bitset<1>        foo1;

            bitset<3>        foo2;

            bitset<4>        foo3;

            long                 anotherMember;

            bitset<1>        bar1;

            bitset<1>        bar2;

};

Where it is stated that bitsets that appear sequentially should be put together. This seems non-intuitive and brittle... In fact the spec recommends not to mix bitsets with other types for readability...

This syntax seems a bit arbitrary and also hard to process by IDL compiler. The XTYPES approach was simpler. If the goal was to avoid "re-purposing" the "enum" then IDL4 could have defined a new keyword, but yet use similar syntax/approach as XTYPES as in:

@bound(16) 

bitset {

    @value(0) FLAG_0;

    @value(1) FLAG_1;

    @value(7) FLAG_7;

    @value(15) FLAG_LAST;

};

 

// OR

@bound(16) 

bitset {

    FLAG_0 = 0;

    FLAG_1 = 1;

    FLAG_7 = 7;

    FLAG_LAST = 15;

};

This is less ambiguous as it separates clearly the size of the bitset from the actual flags-names used for each bit. It also allows the user to not bother assigning explicit values to each bit. Finally the syntax is closer to that of enumeration so it is much easier for IDL parsers to handle it.

Redesign of bitsets

In the previous version of IDL4, bit sets were created to serve two main purposes in a single construct, namely::

• Bit fields (à la C/C++)
• Named accesses to individual bits (as in XTypes)

Rationale for that "all-in-one" approach was to avoid introducing too many new IDL keywords. However, the result was deemed difficult to understand and to implement (notably because a struct had then different meanings and implementation depending if it contains or not bit fields) and not fully compliant with what was designed in XTypes.

The proposal is thus to separate those two things and to design accordingly two different constructs.
The consequence is that it introduces 2 new keywords (bitfield and bitmask) in addition to the existing one (bitset), which is not that annoying as they should not collide too often with existing identifiers (and if they do, IDL provides a mechanism to mitigate the collision).

Supporting empty structures is desired to facilitate the mapping from other data-models that may contain them. In addition the type system in XTYPES already supports them but it is not possible to express it in IDL.

We have found many practical situations where people create empty structures. It may be used these are temporary place holders. Or they can be used as markers for specialized classes that represent different types all inheriting from a common base class.

In all these cases when going to IDL it becomes necessary to add a dummy member like:

struct MyEmptyStruct {
    octet __dummy_member;
};

Note that C and C++ support empty structures. So this should not create problems in the language mappings.

Change <struct_def> in BB Extended Data-types

In BB Extended Data-types, structure definition is already modified to support single inheritance (cf. rule (195)). Complement that extension with the ability of defining void structures.

We’re trying to implement a simple parser based on a subset of the IDL 4.0 BBs, and we’re coming across a number of oversights/mistakes in the language definition. For example, template module instances are required to end with two semicolons.

Invalid:
Typed<FOO> BAR;

Valid:
Typed<FOO> BAR;;

Rule 184 requires a semicolon after a template_module_inst:
(184) <definition> ::+ <template_module_dcl> ";"

Rule 194 defines template_module_inst as ending with a semicolon:
(190) <template_module_inst> ::= "module" <scoped_name> "<" <actual_parameters> ">" <identifier> ";"

There were one or two additional ones that I submitted through the OMG issue process, but never received the customary note from Juergen that it had been received. (unless it went to spam).

I’ll have to dig through my email for specifics of the other, but I believe it was:

Invalid:

struct foo

Valid

struct foo

Invalid:

struct foo

At the moment, we are proceeding under the assumption that such errors are fixed with the intuitive solution in each case, e.g., correct the grammar to allow similar behavior in such cases to IDL 3.5.

I’d like to make sure that our internal resolutions are correct before we invest too much time going down this rabbit hole.

Remove the extra ";" from rule (190)

This is an obvious mistake (the general strategy is that all the ending ";" are specified when adding items to <definition>).
The solution is just to remove that supernumerary piece at the end of rule (190).

In section 7.4.1.4.4.1 Simple Types, section on Char Types the paragraph that follows is redundant with what is already explained in other sections and moreover does not apply to the section. This causes confusion and therefore it should be removed.

The ISO Latin-1 (8859-1) character set standard defines the meaning and representation of all possible graphic characters used in IDL (i.e., the space, alphabetic, digit, and graphic characters defined in Table 7-2 on page 15, Table 7-3 on page 16 and Table 7-4 on page 16). The meaning and representation of the null and formatting characters (see Table 7-5 on page 18) is the numerical value of the character as defined in the ASCII (ISO 646) standard. The meaning of all other characters is implementation-dependent.

Suppress the unnecessary paragrap in section 7.4.1.4.4.1.3

This paragraph overspecifies what is a char. It should be removed.
Note that there is not such a paragraph for wchar.

Consider the following from the standard, which defines a struct:

```
(45) <struct_dcl> ::= <struct_def> | <struct_forward_dcl>
(46) <struct_def> ::= "struct" <identifier> "

"
(47) <member> ::= <type_spec> <declarators> ";"
(67) <declarators> ::= <declarator>

*
```

then all thee above are valid. Is this intended?

Also, rules 65 and 124 appear to suffer the same deficiency:

```
(65) <any_declarators> ::= <any_declarator>

(124) <context_expr> ::= "context" "(" <string_literal>

")"
```

Add the missing '' in the rules 65,67 and 124*

This is just typos resulting from an unfortunate cut and paste.

Rules 65, 67 and 124 should be:
(65) <any_declarators> ::= <any_declarator>

*
(67) <declarators> ::= <declarator>

*
(124) ‎<context_expr>‎ ‎::=‎ ‎"context" "(" <string_literal>

* ")"‎

Nothing else has to be changed in the specification.

<declarators> is defined as <declarator>

*
<any_declarators> := <any_declarator>

*

This better aligns with IDL 3.5 and likely the intention of the standard

Same issue as #1

Mistakes already reported in issue #1

Currently maps are defined to be parameterized only by "simple types". This means that anonymous types cannot be provided even if they are supported in the profile.
This is not consistent with sequence definition where anonymous types can be used (provided that BB Anoymous Types be part of the profile)
=> In rule (198), <simple_type_spec> should be replaced with <type_spec>

Change <simple_type_spec> to <type_spec> in map definition

With this modification, maps will accept anonymous types in parameters (provided that BB Anonymous Types is included)
This is more consistent with sequences (as said in the text).

Currently the default size of a bitmask is 64.
32 is actually used much more often and would be a more suitable default value

Set default value of bitmask size to 32

Amend resolution of issue #5 to set 32 as default value for a bitmask size, instead of 64.