(Possible) Errors in type/member signatures in Annex C, "Standard library"

[RexJaeschke]

I'm making a pass over the type/member declarations in C.2 and C.3, and have found some errors and possible errors. I'll spell out each one in a separate comment below. If you agree with my analysis and recommendation, simply add a thumbs-up; otherwise, add a comment.

(As currently written, these declarations are not complete, so are not extracted and pushed through the example tester mechanism. As such, errors in them have not before been detected.)

[RexJaeschke]

Issue 1: C.2: System.ObsoleteAttribute

We have the following:

public string Message? { get; }

which should instead be

public string? Message { get; }

2025-10-22 Agreed.

[RexJaeschke]

Issue 2: C.2: System.Exception

We have the following:

public class Exception
{
  ...
  public sealed Exception? InnerException { get; }
  ...
}

We added the modifier sealed in Ecma V3 (when we added support for generic types and a few other things). However, neither the CLI nor VS/.NET has this. And with it present VS tells me

CS0238: ExceptionInnerException cannot be sealed because it is not an override (sealed was used on a member that was not also marked with override).

This is confirmed by our spec in §15.6.6, Sealed methods, where we have the following:

When an instance method declaration includes a sealed modifier, that method is said to be a sealed method. A sealed method overrides an inherited virtual method with the same signature. ***A sealed method shall also be marked with the override modifier. ***

From this I deduce that we should remove the sealed modifier. We can't keep it and add override instead, as there is no suitable method to override (CS0115).

2025-10-22 Agreed.

[RexJaeschke]

Issue 3: C.2: System.GC

We have the following:

public class GC { }

However, the CLI spec says this type is sealed while VS/.NET says it is not! What to do?

From Jon: this should be a static class instead.

2025-10-22 Make static per #1378 (comment)

[RexJaeschke]

Issue 4: C.2: System.Nullable<T>

We have the following:

public struct Nullable<T>
{ ... }

However, now that V8 supports where T : struct should we change that to match VS/.NET? This would make it

public struct Nullable<T> where T : struct
{ ... }

which, of course, is beyond what CLI requires.

Jon: I strongly suspect the CLI does require it, and where T : struct has been viable for this for ages. But the fix is correct :)

Rex: Yes, it is in the CLI spec; my mistake.

[RexJaeschke]

Issue 5: C.2: System.Object

We have the following:

public class Object
{
  ...
  public virtual bool Equals(object obj);
  ...
}

However, VS/.NET shows the type of the obj parameter as object?. I presume we should add the ?.

2025-10-22 Agreed.

[KalleOlaviNiemitalo]

Re issue 3:

It looks like System.GC was sealed in .NET Framework 1.1 but then changed to static in .NET Framework 2.0.

In ECMA-334 1st edition December 2001 and 2nd edition December 2002, subclause 17.1.1 did not allow static as a class-modifier. That was added in 3rd edition June 2005.

At this point, I think the C# standard should declare System.GC as a static class, even if ECMA-335 doesn't. This is in principle a breaking change as it prevents user code from using System.GC as a type argument or as the type of a variable; but I doubt such code would be accepted by any implementations currently supported by their vendors.

[RexJaeschke]

Issue 6: C.2: System.String

We have the following:

public sealed class String : IEnumerable<Char>, IEnumerable
{
  public int Length { get; }
  public char this [int index] { get; }
  public static string Format(string format, params object?[] args);
}

However, we don't fulfill the requirements imposed by these interfaces.

In Ecma V1 & V2, we had

public sealed class String: ICloneable, IComparable, IEnumerable`
{
  // 80-odd members
}

In Ecma V3 and V4 (which added support for generic types), and V5, we had

public sealed class String : IEnumerable<Char>, IEnumerable
{
  public int Length { get; }
  public char this[int index] { get; }
}

In Ecma V6 and V7, we had

public sealed class String : IEnumerable<Char>, IEnumerable
{
  public int Length { get; }
  public char this [int index] { get; }
  public static string Format(string format, params object?[] args);
}

The CLI spec does require IEnumerable and the VS/.NET source code does as well.

This interface requires IEnumerable.GetEnumerator() to be implemented, and we don't require that.

The CLI spec does require IEnumerable and the VS/.NET source code does as well.

Interface IEnumerable<Char> requires IEnumerable<Char>.GetEnumerator() to be implemented, and we don't require that either.

My proposed fixes are:

1. Add the member IEnumerator IEnumerable.GetEnumerator(); to this type.
2. Add the member IEnumerator<Char> IEnumerable<Char>.GetEnumerator(); to this type.
3. Change Char to char as in C.2 our convention is to use the keyword version of such types.
   which is the same as Draft V8.

2025-10-22 Agreed.

[RexJaeschke]

Issue 7: Uses of CLI-supported methods not required by our spec.

We have a number of examples and at least one normative occurrence of this. It seems like a bad idea to use members on standard library types/instances that we don't actually require.

Here are some I ran across:

• 8.3.5: The following comments refer to members not required by our spec:

  int i = int.MaxValue; // System.Int32.MaxValue constant
  string s = i.ToString(); // System.Int32.ToString() instance method 
  string t = 123.ToString(); // System.Int32.ToString() instance method

  and while ToString could resolve to Object.ToString, MaxValue need no exist at all.

• 10.3.8: return new C(int.Parse(s));

• 13.8.3: case var o when string.IsNullOrWhiteSpace(o):

• 15.6.2.5: dir = path.Substring(0, i); name = path.Substring(i); where dir and path have type string.

• 22.5.5.2: **NORMATIVE TEXT" The attribute System.Runtime.CompilerServices.CallerLineNumberAttribute is allowed on optional parameters when there is a standard implicit conversion (§10.4.2) from the constant value int.MaxValue.

• 22.5.7.10: The NotNullWhen attribute: String.IsNullOrEmpty(String)

• 23.9: int.MinValue

• 23.9: return new string(p, 0, (int)(buffer + 16 - p)); Our class String has no constructors.

[Nigel-Ecma]

Issue 4: C.2: System.Nullable<T>

We have the following:

public struct Nullable
{ ... }
However, now that V8 supports where T : struct should we change that to match VS/.NET? This would make it

public struct Nullable where T : struct
{ ... }
which, of course, is beyond what CLI requires.

For this one the constraint on T is discussed in the main text so the two would need to be kept in sync, regardless we should probably do this.

[Nigel-Ecma]

Issue 3: C.2: System.GC

We have the following:

public class GC { }
However, the CLI spec says this type is sealed while VS/.NET says it is not! What to do?

I’d probably remove the class entirely from the Standard…

Apart from its name any members/behaviour it has is meant to be implementation defined yet there is normative text such as “The behavior of the garbage collector can be controlled, to some degree, via static methods on the class System.GC. This class can be used to request a collection to occur, finalizers to be run (or not run), and so forth.”

We could of course, rather than remove the type, re-write to either include requirements or be properly implementation neutral…

[RexJaeschke]

Issue 8: C.3: System.IAsyncDisposable

We have the following:

public interface IAsyncDisposable
{
    ValueTask DisposeAsync();
}

which should instead be (with the fully qualified name on the return type)

public interface IAsyncDisposable
{
    System.Threading.Tasks.ValueTask DisposeAsync();
}

[RexJaeschke]

Issue 9: C.3: System.FormattableString

We have the following:

 public class FormattableString : IFormattable { }

However, VS/.NET shows this class as being abstract. Should we follow suit?

[RexJaeschke]

Issue 10: C.3: IAsyncEnumerator<out T>

We have the following:

public interface IAsyncEnumerator<out T> : IAsyncDisposable
{
    ValueTask<bool> MoveNextAsync();
    T Current { get; }
}

which should instead be (with the fully qualified name on the return type)

public interface IAsyncEnumerator<out T> : IAsyncDisposable
{
    System.Threading.Tasks.ValueTask<bool> MoveNextAsync();
    T Current { get; }
}