Bug 11276 – Spurious "explicit slice assignment ...[] is better" warning message in Phobos

This could be a problem in DMD and one related but different in Phobos. This used to work: import std.algorithm: reduce; struct Foo { int x, y; } void main() { Foo[] data = [{10, 20}, {30, 40}]; reduce!((a, b) => a[] += [b.x, b.y][])([0, 0], data); } Now it gives (dmd 2.064beta1): test.d(5): Error: invalid array operation a[] += [b.x, b.y] (did you forget a [] ?) ...\dmd2\src\phobos\std\algorithm.d(763): Error: template instance test.main.__lambda1!(int[], Foo) error instantiating test.d(5): instantiated from here: reduce!(int[], Foo[]) test.d(5): Error: template instance test.main.reduce!((a, b) => a[] += [b.x, b.y][]).reduce!(int[], Foo[]) error instantiating Expanding the lambda doesn't fully solve the problem (now compiling with "-wi"): import std.algorithm: reduce; struct Foo { int x, y; } void main() { Foo[] data = [{10, 20}, {30, 40}]; reduce!((a, b) { int[2] c = [b.x, b.y]; a[] += c[]; return c;})([0, 0], data); } Gives: ...\dmd2\src\phobos\std\algorithm.d(763): Warning: explicit slice assignment result = (__lambda1(result, front(_param_1)))[] is better than result = __lambda1(result, front(_param_1))

W.r.t. diagnostics, I've ran into the following when compiling msgpack-d: ----- C:\dmd-git\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(453): Warning: explicit element-wise assign ment (this._expand_field_3)[] = (another._expand_field_3)[] is better than this._expand_field_3 = anoth er._expand_field_3 C:\dmd-git\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(453): Warning: explicit element-wise assign ment (this._expand_field_4)[] = (another._expand_field_4)[] is better than this._expand_field_4 = anoth er._expand_field_4 ----- It's again an odd diagnostic inside of Phobos. The issue and compile flags are reported here: https://github.com/msgpack/msgpack-d/issues/15

(In reply to comment #0) > This could be a problem in DMD and one related but different in Phobos. > > This used to work: > > import std.algorithm: reduce; > struct Foo { int x, y; } > void main() { > Foo[] data = [{10, 20}, {30, 40}]; > reduce!((a, b) => a[] += [b.x, b.y][])([0, 0], data); > } > > > Now it gives (dmd 2.064beta1): > > test.d(5): Error: invalid array operation a[] += [b.x, b.y] (did you forget a > [] ?) > ...\dmd2\src\phobos\std\algorithm.d(763): Error: template instance > test.main.__lambda1!(int[], Foo) error instantiating > test.d(5): instantiated from here: reduce!(int[], Foo[]) > test.d(5): Error: template instance test.main.reduce!((a, b) => a[] += [b.x, > b.y][]).reduce!(int[], Foo[]) error instantiating This is a duplicate issue of bug 10684. I'll increased importance of the issue. (In reply to comment #0) > Expanding the lambda doesn't fully solve the problem (now compiling with > "-wi"): > > import std.algorithm: reduce; > struct Foo { int x, y; } > void main() { > Foo[] data = [{10, 20}, {30, 40}]; > reduce!((a, b) { int[2] c = [b.x, b.y]; > a[] += c[]; > return c;})([0, 0], data); > } > > Gives: > > ...\dmd2\src\phobos\std\algorithm.d(763): Warning: explicit slice assignment > result = (__lambda1(result, front(_param_1)))[] is better than result = > __lambda1(result, front(_param_1)) This is a regression caused by implementing issue 7444.

(In reply to comment #2) > This is a duplicate issue of bug 10684. I'll increased importance of the issue. > ... > This is a regression caused by implementing issue 7444. Then I have renamed and modified this issue, now it's just about the Phobos warning problem.

(In reply to comment #3) > (In reply to comment #2) > > > This is a duplicate issue of bug 10684. I'll increased importance of the issue. > > ... > > This is a regression caused by implementing issue 7444. > > Then I have renamed and modified this issue, now it's just about the Phobos > warning problem. I think the enh 7444 may not be usable in generic code. Maybe we need to disable 7444 for 2.064 release...

PR to disable the feature that had proposed and implemented by issue 7444. https://github.com/D-Programming-Language/dmd/pull/2673

(In reply to comment #4) > I think the enh 7444 may not be usable in generic code. Maybe we need to > disable 7444 for 2.064 release... Do you plan in restoring 7444 for 2.065? Do you have ideas regarding how to fix this situation and save the 7444?

(In reply to comment #6) > (In reply to comment #4) > > > I think the enh 7444 may not be usable in generic code. Maybe we need to > > disable 7444 for 2.064 release... > > Do you plan in restoring 7444 for 2.065? Do you have ideas regarding how to fix > this situation and save the 7444? If the code is in template instance, compiler can stop warning. It would save the generic code case in this issue. However, currently I have no idea for issue 11244.