Add Support for Indexers and Ranges

[RexJaeschke]

Before you look at the detailed edits, it likely will be useful to read the following:

• 14.7 Properties|14.7.1 General, which defines countable as it pertains to a type.
• 14.(x) Indexable sequences, which defines indexable sequence.

[RexJaeschke]

[I raised the questions below on https://github.com/dotnet/docs/issues/30512, and got replies, which I need to factor in to this Draft PR.]

I'm transforming this proposal into a Draft PR for the C# Standard, and have several questions:

Q1. Optional Members in Index and Range: The proposal suggests that some members in these types are optional, such as Range's StartAt, EndAt, and All. Which members are required for these types? Why not require all those provided by MS's implementation?

Specifically, the MS proposal states:

The .. syntax for System.Range will require the System.Range type, as well as one or more of the following members:

namespace System
{
    public readonly struct Range
    {
        public Range(System.Index start, System.Index end);
        public static Range StartAt(System.Index start);
        public static Range EndAt(System.Index end);
        public static Range All { get; }
    }
}

The .. syntax allows for either, both, or none of its arguments to be absent. Regardless of the number of arguments, the Range constructor is always sufficient for using the Range syntax. However, if any of the other members are present and one or more of the .. arguments are missing, the appropriate member may be substituted.

MS's feedback on my Q was:

The only one required is the constructor: we will fall back to it if any of the others are missing. As to why it was specified this way, I'm not certain, and unfortunately Andy (who implemented it) just went on leave for a few months.

As a result, I'm omitting any mention of the optional members StartAt, EndAt, and All, and defining things in terms of the constructor.

Q2. Range indexer setter: What if anything should we say about the implicit and explicit setter for a Range indexer? Certainly, one can define a setter for a user-defined type; however, it is not obvious as to what such a setter would do, especially since it must be used on the left-hand side of assignment taking a right-hand side of the same type as the index returns. In the case of type BitArray that would mean something like ba1[range1] = ba2, or perhaps ba1[range1] = ba2[range2]. As far as I can determine, the operations one might like to implement using such a setter are probably best implemented via a named method. In any event, for a compiler-generated Range indexer, attempting to use its setter results in the error message “CS0131 The left-hand side of an assignment must be a variable, property or indexer,” which suggests the generated indexer has no setter. If that is the case, we should say that, perhaps by stressing that the result of a Range indexer is not a variable, so as such, it can't be used on the lhs of an assignment.

MS's feedback on my Q was:

I think we should say nothing about it, or at most say that no setter is synthesized if one does not exist. I think the rest of the rules should just fall out from this, as the error implies.

I chose to say nothing about the setter, which means that attempting to use such a setter results in unspecified behavior.

[RexJaeschke]

When adapting the MS proposal, I invented the term indexable sequence. The rationale for that name choice follows.

Various MS-hosted on-line pages use the term sequence. This word is already used quite a bit in the C# spec, in both a general sense as well as being defined in the context of query expressions. §11.17 Query expressions|§11.17.1 General states:

A query expression begins with a from clause and ends with either a select or group clause. The initial from clause may be followed by zero or more from, let, where, join or orderby clauses. Each from clause is a generator introducing a range variable that ranges over the elements of a sequence. Each let clause introduces a range variable representing a value computed by means of previous range variables. ….

That definition is not applicable to indexes and ranges! The MS-provided proposal uses collection; however, that implies enumerable support, which is not required by indexes and ranges. (BTW, although it is used a lot in the C# spec, the term collection is not defined!) As such, rather than overload an existing term or invent a completely different one, I came up with indexable sequence.

[RexJaeschke]

The MS proposal, section “Implicit Range support,” provided a very detailed discussion of how to transform a pair of Indexes into a call to Slice depending on the form of the range used. I did not retain this in the final proposal, as I saw no point in doing so. Given a start and end index, it is a simple matter to compute the length in all cases regardless of range format!, as I show in my range indexer implementation in “Explicit range support.”

[Nigel-Ecma]

The definition of indexable sequence, both original and revised versions, do not fix the type of the index. Here the type is fixed to being an integer number (it does not state the actual type).

[Nigel-Ecma]

How does this mesh with the “behave as if” behaviour specified in the new clause Implicit Index support (classes.md, line 5594)?

This version mentions GetOffset, but are we requiring that it be called or that an implementation may “behave as if” it is? Elsewhere in the Standard there are passages where behaviour is defined to be the “equivalent of executing the following code” (or words to that effect), would that pattern be better here?

[Nigel-Ecma]

This check on P being valid is occurring after the conversion of Index to int which requires P…

[Nigel-Ecma]

I think the valiant attempt to interweave Index and Range is currently a bit hard to follow, well at least I've had to keep re-untangling it as I check the semantics. I think separating out integral, Index and Range cases a bit more would help, I might back it back before the meeting to make a suggestion…

[jnm2]

I think by this list, the following should not error, but it does:

var dict = new X();
dict[^1] = "";

class X : Dictionary<int, string>
{
}

[jskeet]

Here's an unexpected example:

public struct Int32OrRange
{
    public static implicit operator int(Int32OrRange index) => 0;
    public static implicit operator Range(Int32OrRange index) => new Range(0, 0);
}

string[] array = { };
Int32OrRange x = new();
var result = array[x];

That compiles, and uses the conversion to int. If you remove the conversion, it still compiles, and uses the conversion to Range. I'd have expected the first to compile because neither int nor Range is better than the other.

[BillWagner]

I checked with the compiler team. The roslyn implementation ranks single argument indexers in the following order:

• int
• uint
• Int64
• UInt64
• Index
• Range

I wouldn't expect that to change, so we'll have to come up with normative rules that match that behavior.

[Nigel-Ecma]

“transformed by the implementation” is wrong here as:

• there is no requirement that the implementation does this transformation (and Roslyn does not always do so); and
• the Standard uses phrasing like “has the same meaning as” or “is equivalent to” (e.g. §12.8.8, §13.9.5)

[jskeet]

@Nigel-Ecma IIRC you were going to propose a new structure for this (in a new PR, I believe?) - do you think you'll have anything ready in time for us to review by the next meeting? Do let me know if I'm completely wrong on this.

[Nigel-Ecma]

@Nigel-Ecma IIRC you were going to propose a new structure for this (in a new PR, I believe?) - do you think you'll have anything ready in time for us to review by the next meeting? Do let me know if I'm completely wrong on this.

@jskeet – You are correct, but I doubt I’ll have anything ready for the next meeting on this one.

[RexJaeschke]

For the next TG2 call agenda, I propose the following two 15-minute sessions, in order, for this PR, even if Nigel won't have a formal presentation ready:

1. We identify Nigel's main concerns, so we all understand them and can work on addressing them in the weeks following.
2. Separately, we walk through the "File changes" and deal with as many non-controversial corrections and suggestions (lexical, maybe library, and some of the expressions chapter). Once that is done, perhaps we can move the remaining open commits to a new PR, so going forward we don't have to wade through all the comments we just closed/adopted.

[jskeet]

Removing the "meeting: priority" label as #1369 is now the proposal.

[BillWagner]

Closed in favor of #1369