Index and Range should accept negative values, as well.

[ernest-morariu]

The struct System.Index doesn't currently accept negative indexes.

I am quite sure there are a lot of custom collections out there that support negative indexes, but they cannot use the struct System.Index.
The question is: why not let the application decide whether an Index makes sense or not?

Negative indexes would also open the door for negative ranges and that would be a good thing, as well. A range like -7..-3 makes sense for a collection that supports negative indexes.

I may be wrong, but it seems the restriction of Index to positive integer values is dictated only by the current implementation. The author of the struct Index chose to use the negative side of the internal Int32 field to store "from the end" indexes, so it cannot store a negative value that comes from the application.

[CyrusNajmabadi]

Moving to runtime. This is an api, not a language, decision. Thanks!

[huoyaoyuan]

From implementation sight of view, Index uses negative values to represent indices counting from the end.

[stephentoub]

I am quite sure there are a lot of custom collections out there that support negative indexes,

Can you share examples?

[ernest-morariu]

Stephen,

Thank you for your attention.

The API/collection I am working on doesn't need negative indexes. However, it wants to support selecting data based on "directional ranges"(ascending & descending). A "descending range" is something like 9..5 and the API provides the result starting from the index 9 and then all the other values down to 5.
Everything was fine up to the point I realized I cannot indicate a descending range that includes the element at index 0. A range like this would be 5..-1 because the end index must be exclusive. Unfortunately, the current implementation of Index doesn't allow me to specify the -1.

I chose to present this "issue" in a general context of collections that need or maybe prefer to support negative indexes. Why I chose that? Because I am convinced there are such collections. You asked me for an example. Any list of data that can have a kind of "symmetry" with respect to a specific point can be an example, such as a list of temperatures.
Negative indexes support is not something you cannot live without, but not supporting it sounds like "folding the business to what the technology can do".

[tannergooding]

Index was explicitly designed to support "szarray", that is a single-dimensional, zero-based managed arrays. Other types of arrays would need their own index/range types.

Index is therefore unlikely to be changed to support negative values as doing so would negatively impact the vast majority case as we could no longer represent "from the end" efficiently.

As for Range, it simply takes two indexes and does not require those indices be ordered. The range 9..5 already valid and while not all types will accept such ranges, your own types can freely support such concepts. -- While you can specify indices from the array start and array end, there is no way to specify indices from the range start or range end and doing so is also unlikely as it would negatively impact the vast majority case.

Supporting an ending range of 0 is likewise problematic given that the End is considered non-inclusive and we do not have any free bit that would otherwise allow this to work. Thus supporting it would also significantly hurt the vast majority scenario.

[ernest-morariu]

Tanner,

Thank you for your reply.

Sorry for insisting. The fact that Index accepts negative values doesn't mean the application must support them. By "application" I mean the one that receives and processes such Index. The application has the option to raise IndexOutOfRangeException for anything it doesn't like the same way it already does for any index that is not in the proper range. I am trying to say that I don't see the big impact you talk about. It's true that the existing .net API that currently accepts Indexes and Ranges will probably need to validate against negative values and this is probably the big impact you talk about.

In the end, Index and Range are just two insignificant types. Somebody may say "Create your own custom Index and Range and do whatever you want". Yes, I can do that, but I lose the syntax sugar the compiler supports around them, the a..b and the "from the end" indexes (^p) - these are the important thing.
Maybe you guys can do something in this regard, maybe you can extend the capabilities of the compiler such that it accepts the syntax a..b for any Range<T> and Index<T>. (I guess this would be a request for the category "language")

[tannergooding]

I am trying to say that I don't see the big impact you talk about. It's true that the existing .net API that currently accepts Indexes and Ranges will probably need to validate against negative values and this is probably the big impact you talk about.

Index is internally a single int field today. It supports indices from the start of the collection which are internally represented as 0 to +2147483647, inclusive. It then supports indices from the end of the collection which are internally represented as -1 to -2147483648, inclusive.

Thus, the bits that would be used to represent negative indices are "already taken" in order to efficiently support "from end of the collection". In order to support negative indices, we would have to expand System.Index from being a single int field to tracking additional fields and/or state. Doing this would increase the size, increase the complexity in handling the type, and ultimately negatively impact its usage for the majority of scenarios.

Maybe you guys can do something in this regard, maybe you can extend the capabilities of the compiler such that it accepts the syntax a..b for any Range and Index. (I guess this would be a request for the category "language")

Yes, this would be a language request. If the language had a general way to support ranges/indices then such support would be extensible to cases like long, nint, or other scenarios where that was relevant. A user-defined type could then be willing to pay the additional cost to support both "from collection end" and other concepts such as negative indices.

[ernest-morariu]

Thank you all guys for your support. It was nice talking to you.