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.