New Language Features that Rely on Features NOT in the Current CLI Spec

[RexJaeschke]

[After discussing this with Bill, I'm generalizing Kalle's comment for other future features/spec versions.]

As a comment to PR #681, @KalleOlaviNiemitalo wrote:

Should the references to "C# implementations targeting the CLI" be changed somehow because the ECMA standard CLI does not support default interface members? Possible answers include:
• Remove them; C# 8 implementations cannot target "the CLI".
• Change them to say "targeting a CLI with extensions" or the like.
• Keep them; a C# implementation can still target the standard CLI, although the mapping may become complex or inefficient or have restrictions (like not supporting dynamic loading of assemblies that were not provided at build time).

FYI, in the V7 Introduction, we state:

Although Microsoft’s implementation of C# relies on CLI for library and run-time support, other implementations of C# need not, provided they support an alternate way of getting at the minimum CLI features required by this C# standard (see Annex C).

[RexJaeschke]

Adding the Pre-C# 8.0 milestone, as this issue impacts a V8 feature.

[Nigel-Ecma]

I think we can leave the CLI references as is, I don’t think trying to find alternative wording or adding caveats is worth it. (In some sense features added to .NET since the last CLI edition and used by C# are coming in some future edition until the CLI is declared as done/abandoned.)

However what we are missing is a source for the “formal definition of these types and their members” (§C.1) for those types in §C.3 and we should consider how to address that as it leaves a hole in the C# Standard – “What are the semantics of these types?”

While looking at occurrences of CLI I noted the following:

1. In §22.4.3 there is an example starting “In an implementation of the CLI…” but the example does not say why it applies only to C# on the CLI. Is it worth stating this?
2. In $D.4.2 it says “The encoding of each argument is the same as a CLI signature, as follows:” – is there a word missing in that sentence?

[jskeet]

Notes from the meeting October 4th:

• Try to describe the new features without referring to the CLI
• Effectively ignore the fact that "just a CLI" implementation (without any extensions) wouldn't support some of this
• Potentially get XML documentation for the non-CLI-standard-specified types
• Default interface implementation feature will affect this and Consider reordering and reorganizing sections #959; we should probably prioritize that feature (and working out the implications)

[Nigel-Ecma]

I think we can leave the CLI references as is

I think I'll revise that slightly, reading this issue again I see Rex quoted:

Although Microsoft’s implementation of C# relies on CLI for library and run-time support, other implementations of C# need not, provided they support an alternate way of getting at the minimum CLI features required by this C# standard (see Annex C).

The “getting at the minimum CLI features” can be read as the CLI is in there somewhere when it clearly doesn’t need to be. Maybe something along the lines of:

Although Microsoft’s implementation of C# relies on CLI for library and run-time support, other implementations of C# need not, provided they provide the features/API (<- pick one) required by this C# standard (see Annex C).

[RexJaeschke]

The current CLI standard is from June 2012. Since then, the C# standard has added dependencies to library types not in that CLI spec (but which are in MS .NET libraries). It has done this by showing the parent namespace and signatures of the new types and members in Annex C.3; however, no semantics are provided.

The Ecma V5 C# spec was published in 2017, the V6 edition in 2022, and the V7 edition in 2023. The new types and methods introduced in these versions are outlined in Annex C.3 for draft-V8.

Here is a summary of those type names and their parent namespaces, along with anticipated additions through V11, based on Rex’s work thus far on spec’ing future-version features. This may change as we adopt V8+ proposals:

namespace System
{
    public class FormattableString;
V11 public static class MemoryExtensions;
V8  public readonly struct Index;
V8  public struct Range;
    public readonly ref struct ReadOnlySpan<T>;
    public readonly ref struct Span<T>;
V8  public interface IAsyncDisposable;
}
namespace System.Collections.Generic
{
V8  public interface IAsyncEnumerable<out T>;
V8  public interface IAsyncEnumerator<out T>;
}
namespace System.Diagnostics.CodeAnalysis
{
V8  public sealed class AllowNullAttribute;
V8  public sealed class DisallowNullAttribute;
V8  public sealed class DoesNotReturnAttribute;
V8  public sealed class DoesNotReturnIfAttribute;
V8  public sealed class MaybeNullWhenAttribute;
V8  public sealed class MemberNotNullAttribute;
V8  public sealed class MemberNotNullWhenAttribute;
V8  public sealed class NotNullAttribute;
V8  public sealed class NotNullIfNotNullAttribute;
V8  public sealed class NotNullWhenAttribute;
V11 public sealed class SetsRequiredMembersAttribute;
}
namespace System.Linq.Expressions
{
V11 public sealed class Expression<TDelegate>; **NEW METHODS ADDED**
}
namespace System.Runtime.CompilerServices
{
    public sealed class AsyncMethodBuilderAttribute;
V10 public sealed class CallerArgumentExpressionAttribute;
    public sealed class CallerFilePathAttribute;
    public sealed class CallerLineNumberAttribute;
    public sealed class CallerMemberNameAttribute; 
    public static class FormattableStringFactory;
V10 public sealed class InterpolatedStringHandlerArgumentAttribute;
V10 public sealed class InterpolatedStringHandlerAttribute;
V9  public sealed class ModuleInitializerAttribute;
V11 public sealed class RequiredMemberAttribute;
V8  public static class RuntimeHelpers;
V9  public sealed class UnmanagedCallersOnlyAttribute;
    public interface ICriticalNotifyCompletion;
    public interface INotifyCompletion;
V10 public ref struct DefaultInterpolatedStringHandler;
    public readonly struct TaskAwaiter;
    public readonly struct TaskAwaiter<TResult>;
    public readonly struct ValueTaskAwaiter;
    public readonly struct ValueTaskAwaiter<TResult>;
}
namespace System.Threading.Tasks
{
    public class Task;
    public class Task<TResult>;
    public readonly struct ValueTask;
    public readonly struct ValueTask<TResult>;
}

[RexJaeschke]

@KalleOlaviNiemitalo Just to be clear, there are two (sometimes) separate items here: core CLI engine support to implement a C# feature, and CLI library support. The only normative reference to CLI in the C# spec is to "Common Language Infrastructure (CLI), Partition IV: Base Class Library (BCL), Extended Numerics Library, and Extended Array Library." (We do not normatively reference any of the other CLI spec Parts.)

I say this, as the V8 feature "default interface members" has been mentioned as a potential reason for this issue. However, the draft PR for that feature does not mention CLI and it has no stated dependence on any APIs provided by .NET since June 2012 (when the most recent CLI spec was published). So, it seems to me that if an implementation wants to support that feature it has to do so with the syntax/semantics we describe regardless of whether its underlying engine or library provides such support.

[jnm2]

In case it helps, the .NET runtime's augmentations to ECMA-335 are documented here:
https://github.com/dotnet/runtime/blob/main/docs/design/specs/Ecma-335-Augments.md

[jskeet]

@RexJaeschke is foolishly volunteering to remove as many references to the CLI as possible; we'll only refer to the types standardized in the CLI spec. Or we could just remove all references to the CLI and just say "these types are required".

[RexJaeschke]

Review All Mentions of CLI

[In any comment you create, please identify which of the following numbered scenarios you are referring to.]

As of 2025-06-13, draft-v8 contains the following mentions of "CLI," in clause order, along with my suggestion for their disposition. Additions are show as "{{add me}}", and removals are shown as "{{remove me}}", and my suggestion as suggestion:

1. introduction.md: Ecma Technical Committee 39 (TC39) [later renamed to TC49] Task Group 2 (TG2) was formed in September 2000, to produce a standard for C#. Another Task Group, TG3, was also formed at that time to produce a standard for a library and execution environment called Common Language Infrastructure (CLI). (CLI is based on a subset of the .NET Framework.) Although Microsoft's implementation of C# relies on CLI for library and run-time support, other {{conforming}} implementations of C# need not, provided they support the features {{and API}} required by this C# Standard (see Annex C).

2. normative-references.md:ISO/IEC 23271:2012, Common Language Infrastructure (CLI), Partition IV: Base Class Library (BCL), Extended Numerics Library, and Extended Array Library. Leave as is.

3. basic-concepts.md:> Note: This restriction is to allow C# programs to be easily translated to run on {{the Common Language Infrastructure (CLI), which}}{{a platform that}} does not provide a way to define methods that differ solely in in, out, and ref. end note

4. attributes.md:> Example: In an implementation of the CLI, the Help attribute instances in the assembly created by compiling the example program in §22.2.3 can be retrieved with the following program: Remove the whole example.

5. portability-issues.md:1. {{The CLI reserves c}}{{C}}ertain signatures {{are reserved}}} for compatibility with other programming languages (§15.3.10).

6. standard-library.md:A conforming C# implementation shall provide a minimum set of types having specific semantics. These types and their members are listed here, in alphabetical order by namespace and type. For a formal definition of the{{se}} types and their members{{,}} {{** identified in §C.2,**}} refer to ISO/IEC 23271:2012 Common Language Infrastructure (CLI), Partition IV; Base Class Library (BCL), Extended Numerics Library, and Extended Array Library, which are included by reference in this specification. {{For a list of types and their members required beyond those identified in §C.2, see §C.3}}. While this does not fill the hole created by our not having semantics for the C.3 types/members, that is a separate issue.

7. documentation-comments.md:This specification suggests a set of standard tags to be used in documentation comments, but use of these tags is not required, and other tags may be used if desired, as long as the rules of well-formed XML are followed. For C# implementations targeting the CLI, it also provides information about the documentation generator and the format of the documentation file. No information is provided about the documentation viewer. Leave as is.

8. documentation-comments.md:The following information is intended for C# implementations targeting the CLI. Leave as is.

9. documentation-comments.md:- For methods and properties with arguments, the argument list follows, enclosed in parentheses. For those without arguments, the parentheses are omitted. The arguments are separated by commas. The encoding of each argument is the same as a CLI signature, as follows: Leave as is.