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

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.

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.

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.

The use of the Omg.Types name should be changed to OMG.Types.

Every scope containing a constant declaration shall contain a public static partial class.

The "public static partial class" is inconsistent with the examples in 7.2.3.1 above.

The use of "partial" is suspect and cannot span assemblies. It may be useful for forward interface declarations though whose definition appears in another IDL file.