Bug 2635 – $ for user-defined slices should forward to value.length, not global __dollar. Also injected "length" must go.

Good uses of $ came forth in conjunction with infinite ranges and sentinel-terminated ranges (e.g. singly-linked lists). Those don't have a length defined or easily computed, so slicing with range[n .. $] is possible whereas range[n .. m] is not possible. To effect that, no extra opDollar etc. is needed; we can work with the "length" attribute of the value being indexed/sliced. a) In slice expressions and index expressions with ONE argument, $ should expand to value.length, where value is the object being indexed/sliced (if an unnamed temporary, the value is of course only evaluated once). b) In index expressions with multiple arguments, $ expand to value.length(i), where i is the zero-based argument position. This is exactly enough what's needed to make it all work. Infinite ranges may define a symbolic infinite length and overload slicing on it.

I think expanding to length is not always correct, although I do agree that it can be solved with the proposed method. Length is not always the name of the term you would pass to a slice. Example: sorted dictionary (Red-black tree based for instance). A slice of this container would use two key types as slice indexes. So you would have to define a property length that returns a key, which is super unintuitive for people who are trying to use the length property outside a slicing operation (imagine if the key type is string, your length has to return a string). I think the opDollar would suit this rather well, but maybe call it opSliceEnd, or something like that (to follow the spirit of current operator naming scheme).

*** This issue has been marked as a duplicate of issue 7177 ***