Thread overview
[Issue 7753] Support opIndexCreate as part of index operator overloading in user-defined types
May 28, 2015
Sobirari Muhomori
May 29, 2015
Martin Nowak
May 29, 2015
Martin Nowak
Jul 10, 2015
Puneet Goel
Dec 17, 2022
Iain Buclaw
May 10, 2023
ZombineDev
May 28, 2015
https://issues.dlang.org/show_bug.cgi?id=7753

--- Comment #5 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
Whoa, this feature is weird indeed. Given the declaration int[int][int] a; a[0][0]=0 shouldn't work because the AA has no entry with key 0, so a[0] should throw RangeError similar to how b=a[0] throws RangeError.

--
May 29, 2015
https://issues.dlang.org/show_bug.cgi?id=7753

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #6 from Martin Nowak <code@dawg.eu> ---
Igor Stepanov suggested [¹] an opIndex extension.

ref Foo opIndex(bool lvalue)(size_t idx)

Where the compiler would call opIndex!true when an lvalue is required and opIndex!false when an rvalue suffices.

[¹]: http://forum.dlang.org/post/vorfqumugibjcztdrezb@forum.dlang.org

--
May 29, 2015
https://issues.dlang.org/show_bug.cgi?id=7753

--- Comment #7 from Martin Nowak <code@dawg.eu> ---
(In reply to Martin Nowak from comment #6)
> Igor Stepanov suggested [¹] an opIndex extension.
> 
> ref Foo opIndex(bool lvalue)(size_t idx)

A separate opIndexCreate might be better, b/c it allows you to have a ref return for one and an rvalue return for the other function. It also allows to use those operands as polymorphic functions in classes.

--
July 10, 2015
https://issues.dlang.org/show_bug.cgi?id=7753

Puneet Goel <puneet@coverify.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |puneet@coverify.org

--
February 27, 2020
https://issues.dlang.org/show_bug.cgi?id=7753

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--
February 27, 2020
https://issues.dlang.org/show_bug.cgi?id=7753

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Just wanted to post something here.

The call a[b][c][d] = 0 results in different calls (_aaGetY now) than x =
a[b][c][d] (_aaGetRvalueX).

So I think H S Teoh is onto the right path. Having a different opIndex available for assignment (or lvalue manipluation) makes sense and should be straightforward to define.

Now, to define this a little more concretely, I think opIndexCreate should ONLY be used when the entire chain of indexing results in a definite lvalue requirement. This means ONLY opIndexCreate (or AA usage) available in the expression, and the final "call" should be an opAssign or opOpAssign or opIndexOpAssign. I would also throw in opUnary that expects mutation (i.e. ++ or --) because it's currently supported by AAs.

Unfortunately, the existing behavior is somewhat inconsistent:

struct S {
  int x;
  void opUnary(string s : "++")() {++x;}
}

S[int][int] aa;

aa[1][1] = S(1); // ok
aa[2][2].x = 5; // range violation
++aa[3][3]; // range violation

int[int] aa2;

aa2[4] += 3; // ok
++aa2[5]; // ok

void foo(ref int x)

foo(aa2[6]); // range violation

So there is not 100% consistency here. The most rational logical implementation would just require lvalue usage. But the reality is different.

Also note that ++aa[5] does not match ANY operator that would be on the type of aa. There is no opIndexOpUnary akin to opIndexOpAssign. And it doesn't work if your underlying type supports ++. That is an inconsistency that will be tough to duplicate.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=7753

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--
May 10, 2023
https://issues.dlang.org/show_bug.cgi?id=7753

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com

--