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.”

[BillWagner]

rebased on the latest draft-v8 branch on 09/26/2023

[RexJaeschke]

@KalleOlaviNiemitalo I just revisited this PR and resolved all of Kalle's comments. While doing that, I found a requirement I'd added that was incorrect, so I removed that.