www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opIndex() may hide opSlice()

reply XavierAP <n3minis-git yahoo.es> writes:
In their versions without parameters, these two operators would 
be called in the same way. If both are defined, opIndex() is 
called, regardless of lexical definition order, according to my 
test with DMD.

If both (again I'm just talking about the overloads with no 
arguments) are defined within the same type, it's the fault of 
the author. But I would think the compiler should complain.

They can also be inherited, which is sneakier.

The web reference tersely says under its *Slice* Operator 
Overloading chapter [1]:
"To overload a[], simply define opIndex with no parameters."

Should not the overload of opSlice() with no arguments be 
deprecated? Am I missing something?


[1] https://dlang.org/spec/operatoroverloading.html#array-ops
Mar 09
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Mar 10, 2017 at 01:07:33AM +0000, XavierAP via Digitalmars-d wrote:
 In their versions without parameters, these two operators would be
 called in the same way. If both are defined, opIndex() is called,
 regardless of lexical definition order, according to my test with DMD.
 
 If both (again I'm just talking about the overloads with no arguments)
 are defined within the same type, it's the fault of the author. But I
 would think the compiler should complain.
 
 They can also be inherited, which is sneakier.
 
 The web reference tersely says under its *Slice* Operator Overloading
 chapter [1]: "To overload a[], simply define opIndex with no
 parameters."
 
 Should not the overload of opSlice() with no arguments be deprecated?
 Am I missing something?
 
 
 [1] https://dlang.org/spec/operatoroverloading.html#array-ops
Using opSlice() for slicing (i.e., arr[]) is old, backward-compatible behaviour. The recommended usage is to use opSlice to transform range syntax (i.e., arr[1 .. 2]) into a type that opIndex understands, i.e., arr[1, 2..3, 4] is translated to: arr.opIndex(1, arr.opSlice(2,3), 4) T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Mar 09
next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
 On Fri, Mar 10, 2017 at 01:07:33AM +0000, XavierAP via 
 Digitalmars-d wrote:
 
 Should not the overload of opSlice() with no arguments be 
 deprecated?
 Am I missing something?
Using opSlice() for slicing (i.e., arr[]) is old, backward-compatible behaviour.
Yes but again, why not deprecate it, while still supporting it? It could same someone from having their code hidden and replaced in a polymorphic scenario. Granted it may not be a likely use case, but the situation seems to me to go against D's strong compile-time guarantees.
Mar 09
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Mar 10, 2017 at 01:34:13AM +0000, XavierAP via Digitalmars-d wrote:
 On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
 On Fri, Mar 10, 2017 at 01:07:33AM +0000, XavierAP via Digitalmars-d
 wrote:
 
 Should not the overload of opSlice() with no arguments be
 deprecated?
 Am I missing something?
Using opSlice() for slicing (i.e., arr[]) is old, backward-compatible behaviour.
Yes but again, why not deprecate it, while still supporting it? It could same someone from having their code hidden and replaced in a polymorphic scenario. Granted it may not be a likely use case, but the situation seems to me to go against D's strong compile-time guarantees.
I'm not 100% as I wasn't part of the original discussion, but you could file an enhancement request to this effect in the bug tracker. I think it makes sense to add a warning to the effect that opSlice() without arguments should be replaced by opIndex() without arguments in the next release, then turn it into a deprecation in the following release, and then an error in the one after that. But there may be some concerns about this that I'm not aware of. T -- Chance favours the prepared mind. -- Louis Pasteur
Mar 09
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
 On Fri, Mar 10, 2017 at 01:07:33AM +0000, XavierAP via 
 Digitalmars-d wrote:
 The web reference tersely says under its *Slice* Operator 
 Overloading chapter [1]: "To overload a[], simply define 
 opIndex with no parameters."
 
 Should not the overload of opSlice() with no arguments be 
 deprecated?
 Am I missing something?
Using opSlice() for slicing (i.e., arr[]) is old, backward-compatible behaviour.
This seems non-intuitive to me (at least for single dimension containers) - when you see var[], do you think var is being indexed or do you think var is being sliced like an array (equivalent to var[0..$])? Also deprecating nullary opSlice() would work against defining opSlice(int low = 0, int high = length).
Mar 10
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, March 10, 2017 14:15:45 Nick Treleaven via Digitalmars-d wrote:
 On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
 On Fri, Mar 10, 2017 at 01:07:33AM +0000, XavierAP via

 Digitalmars-d wrote:
 The web reference tersely says under its *Slice* Operator
 Overloading chapter [1]: "To overload a[], simply define
 opIndex with no parameters."

 Should not the overload of opSlice() with no arguments be
 deprecated?
 Am I missing something?
Using opSlice() for slicing (i.e., arr[]) is old, backward-compatible behaviour.
This seems non-intuitive to me (at least for single dimension containers) - when you see var[], do you think var is being indexed or do you think var is being sliced like an array (equivalent to var[0..$])?
Yeah, I've never understood how it made any sense for opIndex to be used for slicing, and I've never used it that way. I generally forget that that change was even made precisely because it makes no sense to me, whereas using opSlice for slicing makes perfect sense. I always use opIndex for indexing and opSlice for slicing just like they were originally designed. - Jonathan M Davis
Mar 10
next sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Friday, 10 March 2017 at 15:41:31 UTC, Jonathan M Davis wrote:
 On Friday, March 10, 2017 14:15:45 Nick Treleaven via 
 Digitalmars-d wrote:
 On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
 Using opSlice() for slicing (i.e., arr[]) is old,
 backward-compatible
 behaviour.
This seems non-intuitive to me (at least for single dimension containers) - when you see var[], do you think var is being indexed or do you think var is being sliced like an array (equivalent to var[0..$])?
Yeah, I've never understood how it made any sense for opIndex to be used for slicing, and I've never used it that way. I generally forget that that change was even made precisely because it makes no sense to me, whereas using opSlice for slicing makes perfect sense. I always use opIndex for indexing and opSlice for slicing just like they were originally designed.
I agree, the problem is that the current behavior prefers opIndex(), so deprecating that one would break compatibility. Could be done in phases then. But this isn't really worth much bother of course.
Mar 10
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 10 March 2017 at 15:41:31 UTC, Jonathan M Davis wrote:
 Yeah, I've never understood how it made any sense for opIndex 
 to be used for slicing, and I've never used it that way.
Yeah, I just saw that yesterday in a Phobos type and was like "wtf did they misname it"... but it worked. However, I can get used to it, [] going to opIndex() isn't really a stretch anyway, I would just like if it was better known and the compiler talked about it.
Mar 10
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 10 March 2017 at 15:41:31 UTC, Jonathan M Davis wrote:
 On Friday, March 10, 2017 14:15:45 Nick Treleaven via 
 Digitalmars-d wrote:
 On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
 On Fri, Mar 10, 2017 at 01:07:33AM +0000, XavierAP via

 Digitalmars-d wrote:
 The web reference tersely says under its *Slice* Operator 
 Overloading chapter [1]: "To overload a[], simply define 
 opIndex with no parameters."

 Should not the overload of opSlice() with no arguments be
 deprecated?
 Am I missing something?
Using opSlice() for slicing (i.e., arr[]) is old, backward-compatible behaviour.
This seems non-intuitive to me (at least for single dimension containers) - when you see var[], do you think var is being indexed or do you think var is being sliced like an array (equivalent to var[0..$])?
Yeah, I've never understood how it made any sense for opIndex to be used for slicing, and I've never used it that way. I generally forget that that change was even made precisely because it makes no sense to me, whereas using opSlice for slicing makes perfect sense. I always use opIndex for indexing and opSlice for slicing just like they were originally designed. - Jonathan M Davis
Indexing is a bit like slicing with only 1 element. Slicing is the generalisation of the indexing operation. I think it's quite logical. This said I know nothing about the rationale and discussions about that subject. This was purely my wag (wild ass guess).
Mar 10
prev sibling next sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Friday, 10 March 2017 at 14:15:45 UTC, Nick Treleaven wrote:
 Also deprecating nullary opSlice() would work against defining 
 opSlice(int low = 0, int high = length).
The same call [] can go to a variadic opIndex(T[] indices ...) So many possibilities :_)
Mar 10
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Mar 10, 2017 at 07:41:31AM -0800, Jonathan M Davis via Digitalmars-d
wrote:
 On Friday, March 10, 2017 14:15:45 Nick Treleaven via Digitalmars-d wrote:
 On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
[...]
 Using opSlice() for slicing (i.e., arr[]) is old,
 backward-compatible behaviour.
This seems non-intuitive to me (at least for single dimension containers) - when you see var[], do you think var is being indexed or do you think var is being sliced like an array (equivalent to var[0..$])?
Yeah, I've never understood how it made any sense for opIndex to be used for slicing, and I've never used it that way.
It's very simple, really. Under the old behaviour, you have: arr[] ---> arr.opSlice() arr[x] ---> arr.opIndex(x) arr[x..y] ---> arr.opSlice(x,y) This made implementing higher-dimensional slicing operators hard to define, especially if you want mixed slicing and indexing (aka subdimensional slicing): arr[x, y] ---> arr.opIndex(x, y) arr[x, y..x] ---> ? arr[x..y, z] ---> ? arr[w..x, y..z] ---> arr.opSlice(w, x, y, z) // ? Kenji's insight was that we can solve this problem by homogenizing opSlice and opIndex, such that [] *always* translates to opIndex, and .. always translates to opSlice. So, under the new behaviour: arr[] ---> arr.opIndex() arr[x] ---> arr.opIndex(x) arr[x,y] ---> arr.opIndex(x,y) arr[x..y] ---> arr.opIndex(arr.opSlice(x,y)) arr[x, y..z] ---> arr.opIndex(x, arr.opSlice(y,z)) arr[x..y, z] ---> arr.opIndex(arr.opSlice(x,y), z) This allows mixed-indexing / subdimensional slicing to consistently use opIndex, with opSlice returning objects representing index ranges, so that in a multidimensional user type, you could unify all the cases under a single definition of opIndex: IndexRange opSlice(int x, int y) { ... } auto opIndex(I...)(I indices) { foreach (idx; indices) { static if (is(typeof(idx) == IndexRange)) { // this index is a slice } else { // this index is a single index } } } Without this unification, you'd have to implement 2^n different overloads of opIndex / opSlice in order to handle all cases of subdimensional slicing in n dimensions. So you can think of it simply as: [] == opIndex .. == opSlice in all cases. It is more uniform this way, and makes perfect sense to me.
 I generally forget that that change was even made precisely because it
 makes no sense to me, whereas using opSlice for slicing makes perfect
 sense. I always use opIndex for indexing and opSlice for slicing just
 like they were originally designed.
[...] This is probably why Kenji didn't deprecate the original use of opSlice, since for the 1-dimensional case the homogenization of opSlice / opIndex is probably unnecessary and adds extra work for the programmer: if you want to implement arr[x..y] you have to write both opSlice and an opIndex overload that accepts what opSlice returns, as opposed to just writing a single opSlice. So probably we should leave it the way it is (and perhaps clarify that in the spec), as deprecating the "old" use of opSlice in the 1-dimensional case would cause problems. T -- Chance favours the prepared mind. -- Louis Pasteur
Mar 10
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 10 March 2017 at 18:43:43 UTC, H. S. Teoh wrote:
 So probably we should leave it the way it is (and perhaps 
 clarify that in the spec), as deprecating the "old" use of 
 opSlice in the 1-dimensional case would cause problems.
ndslice just recently added an indexed function http://docs.algorithm.dlang.io/latest/mir_ndslice_topology.html#.indexed that is like slicing based on some index. Other languages have something similar. However, it's not something that's built-in in D. Thus, given the indexed example: auto source = [1, 2, 3, 4, 5]; auto indexes = [4, 3, 1, 2, 0, 4].sliced; auto ind = source.indexed(indexes); there's way to instead write auto source = [1, 2, 3, 4, 5]; auto indexes = [4, 3, 1, 2, 0, 4].sliced; auto ind = source[indexes]; So to me, there does seem scope for some changes, even if they aren't the changes you mentioned in your post.
Mar 10
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 10 March 2017 at 18:43:43 UTC, H. S. Teoh wrote:
 	IndexRange opSlice(int x, int y) { ... }
Why is opSlice a method-operator? Wouldn't it be better if you could do something more general auto idx_selection = (1,3,5); // select element 1, 3 and 5 auto idx_range = (0..4); // select element 0,1,2,3 auto idx_mixed = (0..3,4,5) // select 0,1,2,4,5 auto idx2d_range = [(0..4,5), (0..6)] // select intersections of rows and columns etc...
Mar 12
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, March 10, 2017 10:43:43 H. S. Teoh via Digitalmars-d wrote:
 On Fri, Mar 10, 2017 at 07:41:31AM -0800, Jonathan M Davis via 
Digitalmars-d wrote:
 On Friday, March 10, 2017 14:15:45 Nick Treleaven via Digitalmars-d 
wrote:
 On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
[...]
 Using opSlice() for slicing (i.e., arr[]) is old,
 backward-compatible behaviour.
This seems non-intuitive to me (at least for single dimension containers) - when you see var[], do you think var is being indexed or do you think var is being sliced like an array (equivalent to var[0..$])?
Yeah, I've never understood how it made any sense for opIndex to be used for slicing, and I've never used it that way.
It's very simple, really. Under the old behaviour, you have: arr[] ---> arr.opSlice() arr[x] ---> arr.opIndex(x) arr[x..y] ---> arr.opSlice(x,y) This made implementing higher-dimensional slicing operators hard to define, especially if you want mixed slicing and indexing (aka subdimensional slicing): arr[x, y] ---> arr.opIndex(x, y) arr[x, y..x] ---> ? arr[x..y, z] ---> ? arr[w..x, y..z] ---> arr.opSlice(w, x, y, z) // ? Kenji's insight was that we can solve this problem by homogenizing opSlice and opIndex, such that [] *always* translates to opIndex, and .. always translates to opSlice. So, under the new behaviour: arr[] ---> arr.opIndex() arr[x] ---> arr.opIndex(x) arr[x,y] ---> arr.opIndex(x,y) arr[x..y] ---> arr.opIndex(arr.opSlice(x,y)) arr[x, y..z] ---> arr.opIndex(x, arr.opSlice(y,z)) arr[x..y, z] ---> arr.opIndex(arr.opSlice(x,y), z) This allows mixed-indexing / subdimensional slicing to consistently use opIndex, with opSlice returning objects representing index ranges, so that in a multidimensional user type, you could unify all the cases under a single definition of opIndex: IndexRange opSlice(int x, int y) { ... } auto opIndex(I...)(I indices) { foreach (idx; indices) { static if (is(typeof(idx) == IndexRange)) { // this index is a slice } else { // this index is a single index } } } Without this unification, you'd have to implement 2^n different overloads of opIndex / opSlice in order to handle all cases of subdimensional slicing in n dimensions. So you can think of it simply as: [] == opIndex .. == opSlice in all cases. It is more uniform this way, and makes perfect sense to me.
Well, thanks for the explanation, but I'm sure that part of the problem here is that an operation like arr[x, y..z] doesn't even make sense to me. I have no idea what that does. But I don't normally do anything with multidimensional arrays, and in the rare case that I do, I certainly don't need to overload anything for them. I just slap together a multidimensional array of whatever type it is I want in a multidimensional array. I can certainly understand that there are folks who really do care about this stuff, but it's completely outside of what I deal with, and for anything I've ever dealt with, making opIndex be for _slicing_ makes no sense whatsoever, and the added functionality to the language with regards to multi-dimensional arrays is useless. So, this whole mess has always felt like I've had something nonsensical thrown at me because of a use case that I don't even properly understand.
 I generally forget that that change was even made precisely because it
 makes no sense to me, whereas using opSlice for slicing makes perfect
 sense. I always use opIndex for indexing and opSlice for slicing just
 like they were originally designed.
[...] This is probably why Kenji didn't deprecate the original use of opSlice, since for the 1-dimensional case the homogenization of opSlice / opIndex is probably unnecessary and adds extra work for the programmer: if you want to implement arr[x..y] you have to write both opSlice and an opIndex overload that accepts what opSlice returns, as opposed to just writing a single opSlice. So probably we should leave it the way it is (and perhaps clarify that in the spec), as deprecating the "old" use of opSlice in the 1-dimensional case would cause problems.
Well, I'd prefer that the original way be left, since that's all I've ever needed. If the new way makes life easier for the scientific programmers and whatnot, then great, but from the standpoint of anyone not trying to provide multi-dimensional overloads, using opIndex for slicing is just plain bizarre. That being said, I'm fine with the compiler detecting if opIndex and opSlice are declared in a way that they conflict and then giving an error. I just don't want to be forced to use opIndex for slicing. - Jonathan M Davis
Mar 10
parent XavierAP <n3minis-git yahoo.es> writes:
On Friday, 10 March 2017 at 20:36:35 UTC, Jonathan M Davis wrote:
 problem here is that an operation like arr[x, y..z] doesn't 
 even make sense to me. I have no idea what that does.
https://www.mathworks.com/help/matlab/math/matrix-indexing.html#f1-85544 You can stop reading as soon as it starts talking about "linear indexing". However if you're also curious what that means: https://www.mathworks.com/help/matlab/math/matrix-indexing.html#f1-85511
Mar 10
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Mar 10, 2017 at 12:36:35PM -0800, Jonathan M Davis via Digitalmars-d
wrote:
 On Friday, March 10, 2017 10:43:43 H. S. Teoh via Digitalmars-d wrote:
[...]
 Well, thanks for the explanation, but I'm sure that part of the
 problem here is that an operation like arr[x, y..z] doesn't even make
 sense to me. I have no idea what that does.
That's a subdimensional slice. In this case, we're dealing with a 2D array -- you can think of it as a matrix -- and extracting the y'th to z'th elements from column x. Conversely, arr[x..y, z] extracts the x'th to y'th elements from row z. This kind of subdimensional slicing is pretty common when you work with things like tensors.
 But I don't normally do anything with multidimensional arrays, and in
 the rare case that I do, I certainly don't need to overload anything
 for them. I just slap together a multidimensional array of whatever
 type it is I want in a multidimensional array.
If by "multidimensional arrays" you mean arrays of arrays, then I can understand your sentiment. But when dealing with high-dimensional tensors, storing them explicitly may not always be the best approach. Think sparse matrices, for example. You want to be able to provide array indexing / slicing operations to user types apart from the built-in arrays. Not to mention that there are many problems with using arrays of arrays as "multidimensional" arrays, besides storage issues. One being that you can't easily represent a slice of an array of arrays across the minor dimension (i.e., a slice of every i'th element of each array in an int[][]). For things like that, you *really* want to be able to write arr[x, y..z] and arr[x..y, z] rather than arr[x][y..z] and arr[x..y][z]. Doing it the latter way means you need to implement arr.opSlice that returns a proxy type that implements opIndex. Kenji's design allows you to implement all of these cases (and more) by just implementing a single type with a single opSlice and single opIndex, and no proxy types, to boot. It's clean and elegant.
 I can certainly understand that there are folks who really do care
 about this stuff, but it's completely outside of what I deal with, and
 for anything I've ever dealt with, making opIndex be for _slicing_
 makes no sense whatsoever, and the added functionality to the language
 with regards to multi-dimensional arrays is useless. So, this whole
 mess has always felt like I've had something nonsensical thrown at me
 because of a use case that I don't even properly understand.
Please don't denigrate something as useless without at least trying to understand it first. [...]
 Well, I'd prefer that the original way be left, since that's all I've
 ever needed. If the new way makes life easier for the scientific
 programmers and whatnot, then great, but from the standpoint of anyone
 not trying to provide multi-dimensional overloads, using opIndex for
 slicing is just plain bizarre.
Actually, it's the distinction between opSlice and opIndex in the old scheme that's what's bizarre. It's like saying that to implement userType(x) you need to declare userType.opSingleArgCall and to implement userType(x,y) you need to declare userType.opTwoArgCall, just because there happens to be 2 arguments instead of 1. Why not just unify the two under a single opCall, just with two overloads depending on what arguments you want to pass to it? In the same vein, requiring two different methods to implement arr[x] vs. arr[x..y] is bizarre. They should be unified under a single method -- I don't care what you call it, maybe opIndex is a bad name because it gives the wrong connotation for what it does, maybe it should be named opSquareBrackets or something. But the point is that this distinction between how arr[x] and arr[x..y] are handled is artificial and needless, and does not easily generalize to higher dimensions. Kenji's design is far superior.
 That being said, I'm fine with the compiler detecting if opIndex and
 opSlice are declared in a way that they conflict and then giving an
 error. I just don't want to be forced to use opIndex for slicing.
[...] Nobody is forcing you to use opIndex for slicing right now, because the compiler currently accepts the old syntax for 1-dimensional arrays. And I already said it's probably a bad idea to deprecate the old syntax. T -- What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??
Mar 10
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, March 10, 2017 14:07:59 H. S. Teoh via Digitalmars-d wrote:
 On Fri, Mar 10, 2017 at 12:36:35PM -0800, Jonathan M Davis via 
Digitalmars-d wrote:
 I can certainly understand that there are folks who really do care
 about this stuff, but it's completely outside of what I deal with, and
 for anything I've ever dealt with, making opIndex be for _slicing_
 makes no sense whatsoever, and the added functionality to the language
 with regards to multi-dimensional arrays is useless. So, this whole
 mess has always felt like I've had something nonsensical thrown at me
 because of a use case that I don't even properly understand.
Please don't denigrate something as useless without at least trying to understand it first.
As I said, for what _I_ deal with, it's useless. It's obviously useful to some subset of programmers - particularly folks doing scientific stuff based on what I've seen about posts about multi-dimensional arrays - but it's useless to me. I did not mean to denigrate anything, so sorry if that wasn't clear. My point is that I don't want to have to worry about it or be affected by it when it is useless to me - particularly when I'd have to spend some time studying it to understand it properly. About the only time I've dealt with matrices in any real way was when I took linear algebra, and I've forgotten almost everything from that class. It simply has nothing to do with anything that I've ever needed to program, and I'd just as soon avoid any kind of math that would require it. So, as long as the multi-dimensional slicing stuff sits in its own little corner of the language where I don't have to deal with it, I'm fine. I just want to keep using opSlice for slicing and opIndex for indexing, because that makes sense to me and my needs, whereas using opIndex for a slicing operation just seems wrong, much as it apparently has a benefit for generic code dealing with multi-dimensional indexing and slicing. And as long as the current situation with opSlice working for slicing like it always has continues, I don't care what the subset of programmers who care about multi-dimensional arrays do with opIndex. Unfortunately, it comes up periodically that someone pushes for everything to change to use opIndex for slicing or even to deprecate opSlice for slicing even when the code has nothing to do with multi-dimensional indexing or slicing, and I do object to that. If no multi-dimensional indexing or slicing is involved, I think that opSlice should be used for slicing, not opIndex. Fortunately though, there hasn't been a real push to move everything to use opIndex instead of opSlice and get rid of the original behavior, and I hope that that stays the case. Regardless, thank you for your thorough explanation as to why it was changed so that opIndex could be used for a slicing operation. - Jonathan M Davis
Mar 10