[Issue 15582] Slice returned by opSlice() not accepted as lvalue

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Fri Jan 22 10:37:59 PST 2016


https://issues.dlang.org/show_bug.cgi?id=15582

Marc Schütz <schuetzm at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #4 from Marc Schütz <schuetzm at gmx.net> ---
(In reply to b2.temp from comment #3)
> Actually you overload the wrong operator, because this works:
> 
> struct S {
>     int[10] data;
>     void opIndexAssign(int v) {data[] = v;}
> }
> 
> void main() {
>     S s;
>     s[] = 10;
> }
> 
> So I suggest you to close the issue.

No, the overloaded operator actually doesn't matter, it's just how I discovered
the problem. As I said, even a slice returned by a normal method (or function)
should be assignable, in fact it doesn't matter where that slice came from.

The rule should be simple; for any `<slice> = <value>`:

* if <slice> is an rvalue, do element-wise assignment from value
  => this handles my example as well as the normal slice assignment operator
  int[] a = [4,5,6], b = a;
  a[] = 42;
  assert(a == [42,42,42]);
  a[] = [1,2,3];
  assert(a == [1,2,3]);
  assert(a is b);
  S s;
  s[] = 42;
  s[] = [1,2,3];

* if <slice> is an lvalue and <value> is itself a slice of the correct type,
assign the slice to the lvalue
  int[] a = [4,5,6], b = a;
  a = [1,2,3];
  assert(a !is b);
  // not applicable for `S`, because `opSlice()` returns an lvalue

* if <slice> is an lvalue and <value> has the slice's element type, error
  int[] a = [4,5,6], b = a;
  a = 42; // error
  // not applicable for `S`, because `opSlice()` returns an lvalue

As you can see, built-in slices already work along these rules. But it's
currently not possible to construct a user-defined type that behaves the same
way, except by using `alias this` (often too blunt), or by overloading all
kinds of operators (too tedious).

--


More information about the Digitalmars-d-bugs mailing list