-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Support for Indexers and Ranges #605
base: draft-v8
Are you sure you want to change the base?
Conversation
[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:
MS's feedback on my Q was:
As a result, I'm omitting any mention of the optional members 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 chose to say nothing about the setter, which means that attempting to use such a setter results in unspecified behavior. |
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:
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. |
The MS proposal, section “Implicit Range support,” provided a very detailed discussion of how to transform a pair of Indexes into a call to |
c810a4a
to
867ba90
Compare
7d39754
to
9e74541
Compare
rebased on the latest draft-v8 branch on 09/26/2023 |
- added non-virtual requirement to 2 x imp-generated indexers. - described `GetOffset` semantics. - removed erroneous text w.r.t optional trailing params on `this[int]`.
@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. |
Before you look at the detailed edits, it likely will be useful to read the following: