https://issues.dlang.org/show_bug.cgi?id=15582
Marc Schütz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #4 from Marc Schütz <[email protected]> --- (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). --
