I'd like to propose a new language feature to D community.

I've opened a enhancement issue half a year ago.

  Issue 6798 - Integrate overloadings for multidimentional indexing and slicing
  http://d.puremagic.com/issues/show_bug.cgi?id=6798

And, a pull request for implementing it is now available.

  https://github.com/D-Programming-Language/dmd/pull/443

----
This patch is an additional enhancement of opDollar (issue 3474 and #442). It would enable the mixing operator overloadings of indexing and slicing.

The expression:
  a[$-1, 2..$]
Translated to:
  a.opIndex(a.opDollar!0 - 1, a.opSlice!1(2, a.opDollar!1))

If it is possible, the interval lwr..upr inside bracket is converted
to a.opSlice!(dimension)(lwr, upr).
This enhancement doesn't break existing codes.

(Same table more readable is in
 https://github.com/D-Programming-Language/dmd/pull/443 )

   | expression         | newly added overloading  -->
exists/fallbcked overloading
---+--------------------+------------------------------------------------------------
   | a[i0, ...]         | xxx  -->  a.opIndex(i0, ...)
   | a[]                | a.opIndex()  -->  a.opSlice()
   | a[l..u]            | a.opIndex(a.opSlice!0(l, u))  -->  a.opSlice(l, u)
 v | a[l..u, ...]       | a.opIndex(a.opSlice!0(l, u), ...)  -->  xxx
---+--------------------+------------------------------------------------------------
   | op a[i0, ...]      | xxx  -->  a.opIndexUnary!op(i0, ...)
   | op a[]             | a.opIndexUnary!op()  -->  a.opSliceUnary!op()
   | op a[l..u]         | a.opIndexUnary!op(a.opSlice!0(l, u))  -->
a.opSliceUnary!op(l, u)
 v | op a[l..u, ...]    | a.opIndexUnary!op(a.opSlice!0(l, u), ...)  -->  xxx
---+--------------------+------------------------------------------------------------
   | a[i0, ...] = v     | xxx  -->  a.opIndexAssign(v, i0, ...)
   | a[] = v            | a.opIndexAssign(v)  -->  a.opSliceAssign(v)
   | a[l..u] = v        | a.opIndexAssign(v, a.opSlice!0(l, u))  -->
a.opSliceAssign(v, l, u)
 v | a[l..u, ...] = v   | a.opIndexAssign(v, a.opSlice!0(l, u), ...)  -->  xxx
---+--------------------+------------------------------------------------------------
   | a[i0, ...] op= v   | xxx  -->  a.opIndexOpAssign!op(v, i0, ...)
   | a[] op= v          | a.opIndexOpAssign!op(v)  -->  a.opSliceOpAssign!op(v)
   | a[l..u] op= v      | a.opIndexOpAssign!op(v, a.opSlice!0(l, u))
-->  a.opSliceOpAssign!op(v, l, u)
 v | a[l..u, ...] op= v | a.opIndexOpAssign!op(v, a.opSlice!0(l, u),
...)  -->  xxx

Thanks.

Kenji Hara

This would be very cool indeed!

+1 from me.

On 01/06/2012 02:57, kenji hara wrote:
> I'd like to propose a new language feature to D community.
>
> I've opened a enhancement issue half a year ago.
>
>    Issue 6798 - Integrate overloadings for multidimentional indexing and slicing
>    http://d.puremagic.com/issues/show_bug.cgi?id=6798
>
> And, a pull request for implementing it is now available.
>
>    https://github.com/D-Programming-Language/dmd/pull/443
>
> ----
> This patch is an additional enhancement of opDollar (issue 3474 and #442).
> It would enable the mixing operator overloadings of indexing and slicing.
>
> The expression:
>    a[$-1, 2..$]
> Translated to:
>    a.opIndex(a.opDollar!0 - 1, a.opSlice!1(2, a.opDollar!1))
>
> If it is possible, the interval lwr..upr inside bracket is converted
> to a.opSlice!(dimension)(lwr, upr).
> This enhancement doesn't break existing codes.
>
> (Same table more readable is in
>   https://github.com/D-Programming-Language/dmd/pull/443 )
>
>     | expression         | newly added overloading  -->
> exists/fallbcked overloading
> ---+--------------------+------------------------------------------------------------
>     | a[i0, ...]         | xxx  -->  a.opIndex(i0, ...)
>     | a[]                | a.opIndex()  -->  a.opSlice()
>     | a[l..u]            | a.opIndex(a.opSlice!0(l, u))  -->  a.opSlice(l, u)
>   v | a[l..u, ...]       | a.opIndex(a.opSlice!0(l, u), ...)  -->  xxx
> ---+--------------------+------------------------------------------------------------
>     | op a[i0, ...]      | xxx  -->  a.opIndexUnary!op(i0, ...)
>     | op a[]             | a.opIndexUnary!op()  -->  a.opSliceUnary!op()
>     | op a[l..u]         | a.opIndexUnary!op(a.opSlice!0(l, u))  -->
> a.opSliceUnary!op(l, u)
>   v | op a[l..u, ...]    | a.opIndexUnary!op(a.opSlice!0(l, u), ...)  -->  xxx
> ---+--------------------+------------------------------------------------------------
>     | a[i0, ...] = v     | xxx  -->  a.opIndexAssign(v, i0, ...)
>     | a[] = v            | a.opIndexAssign(v)  -->  a.opSliceAssign(v)
>     | a[l..u] = v        | a.opIndexAssign(v, a.opSlice!0(l, u))  -->
> a.opSliceAssign(v, l, u)
>   v | a[l..u, ...] = v   | a.opIndexAssign(v, a.opSlice!0(l, u), ...)  -->  xxx
> ---+--------------------+------------------------------------------------------------
>     | a[i0, ...] op= v   | xxx  -->  a.opIndexOpAssign!op(v, i0, ...)
>     | a[] op= v          | a.opIndexOpAssign!op(v)  -->  a.opSliceOpAssign!op(v)
>     | a[l..u] op= v      | a.opIndexOpAssign!op(v, a.opSlice!0(l, u))
> -->  a.opSliceOpAssign!op(v, l, u)
>   v | a[l..u, ...] op= v | a.opIndexOpAssign!op(v, a.opSlice!0(l, u),
> ...)  -->  xxx
>
> Thanks.
>
> Kenji Hara
>

kenji hara:

> I'd like to propose a new language feature to D community.

I think this was discussed and generally appreciated. It seems an improvement. Thank you Kenji.

Bye,
bearophile

On 06/01/12 03:57, kenji hara wrote:
> I'd like to propose a new language feature to D community.
> 
> I've opened a enhancement issue half a year ago.
> 
>   Issue 6798 - Integrate overloadings for multidimentional indexing and slicing
>   http://d.puremagic.com/issues/show_bug.cgi?id=6798
> 
> And, a pull request for implementing it is now available.
> 
>   https://github.com/D-Programming-Language/dmd/pull/443

This is _pure awesomeness_ :) Thx !

On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote:
> I'd like to propose a new language feature to D community.
> ...
> This patch is an additional enhancement of opDollar (issue 3474 and #442).


Sounds awesome. However, the name opDollar should be changed to
something like opSize, opLength, opEnd or almost anything else
than the current name.

On 03/06/12 19:31, tn wrote:
> On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote:
>> I'd like to propose a new language feature to D community.
>> ...
>> This patch is an additional enhancement of opDollar (issue 3474 and
>> #442).
>
>
> Sounds awesome. However, the name opDollar should be changed to
> something like opSize, opLength, opEnd or almost anything else
> than the current name.

opDollar is a pretty awful name but nobody could come up with something that is less awful. At least it is not confusing. Everybody instantly knows what it does.
For built-in arrays $ is the length and the size, but that isn't generally true.

Wish we had a better name, but opLength isn't it, and nor is opSize.
opEnd might be the best of those three, but it kinda sounds like something to do with ranges.

On 04.06.2012 13:57, Don Clugston wrote:
> On 03/06/12 19:31, tn wrote:
>> On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote:
>>> I'd like to propose a new language feature to D community.
>>> ...
>>> This patch is an additional enhancement of opDollar (issue 3474 and
>>> #442).
>>
>>
>> Sounds awesome. However, the name opDollar should be changed to
>> something like opSize, opLength, opEnd or almost anything else
>> than the current name.
>
> opDollar is a pretty awful name but nobody could come up with something
> that is less awful. At least it is not confusing. Everybody instantly
> knows what it does.
> For built-in arrays $ is the length and the size, but that isn't
> generally true.
>
> Wish we had a better name, but opLength isn't it, and nor is opSize.
> opEnd might be the best of those three, but it kinda sounds like
> something to do with ranges.

opEndSymbol ? It's no dollar but it's clear what it overloads.

-- 
Dmitry Olshansky

On Monday, June 04, 2012 14:00:18 Dmitry Olshansky wrote:
> On 04.06.2012 13:57, Don Clugston wrote:
> > On 03/06/12 19:31, tn wrote:
> >> On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote:
> >>> I'd like to propose a new language feature to D community.
> >>> ...
> >>> This patch is an additional enhancement of opDollar (issue 3474 and
> >>> #442).
> >> 
> >> Sounds awesome. However, the name opDollar should be changed to something like opSize, opLength, opEnd or almost anything else than the current name.
> > 
> > opDollar is a pretty awful name but nobody could come up with something
> > that is less awful. At least it is not confusing. Everybody instantly
> > knows what it does.
> > For built-in arrays $ is the length and the size, but that isn't
> > generally true.
> > 
> > Wish we had a better name, but opLength isn't it, and nor is opSize. opEnd might be the best of those three, but it kinda sounds like something to do with ranges.
> 
> opEndSymbol ? It's no dollar but it's clear what it overloads.

TDPL already lists opDollar, and it's overloading the $ operator, so I would dispute that a better name _could_ exist. That would be like saying that opEquals would be better if it were renamed to opDoubleEqualSign.

- Jonathan M Davis

On Monday, 4 June 2012 at 10:07:38 UTC, Jonathan M Davis wrote:
> TDPL already lists opDollar, and it's overloading the $ operator, so I would
> dispute that a better name _could_ exist. That would be like saying that
> opEquals would be better if it were renamed to opDoubleEqualSign.

Actually, I'd say its the other way round – opDollar rather corresponds to opDoubleEqualSign, as it simply describes the character used. But I agree that there isn't really a good reason to change opDollar at this point.

David

On Monday, 4 June 2012 at 10:00:20 UTC, Dmitry Olshansky wrote:
> On 04.06.2012 13:57, Don Clugston wrote:
>> On 03/06/12 19:31, tn wrote:
>>> On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote:
>>>> I'd like to propose a new language feature to D community.
>>>> ...
>>>> This patch is an additional enhancement of opDollar (issue 3474 and
>>>> #442).
>>>
>>>
>>> Sounds awesome. However, the name opDollar should be changed to
>>> something like opSize, opLength, opEnd or almost anything else
>>> than the current name.
>>
>> opDollar is a pretty awful name but nobody could come up with something
>> that is less awful. At least it is not confusing. Everybody instantly
>> knows what it does.
>> For built-in arrays $ is the length and the size, but that isn't
>> generally true.
>>
>> Wish we had a better name, but opLength isn't it, and nor is opSize.
>> opEnd might be the best of those three, but it kinda sounds like
>> something to do with ranges.
>
> opEndSymbol ? It's no dollar but it's clear what it overloads.

Maybe opUpperBound or opUBound?