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

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

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.

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

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

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

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.

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.

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 :_)

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