[Issue 24481] New: retro no longer works with types that support assignment but not moving
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Thu Apr 4 00:46:32 UTC 2024
https://issues.dlang.org/show_bug.cgi?id=24481
Issue ID: 24481
Summary: retro no longer works with types that support
assignment but not moving
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nobody at puremagic.com
Reporter: issues.dlang at jmdavisProg.com
https://github.com/dlang/phobos/pull/8721#issuecomment-2035620659
This PR results in issues at Weka with retro for a struct that has void
opAssign()(auto ref const(typeof(this)) that) const defined, i.e. a struct that
allows const assignment. The problem is that assignment is allowed, but move is
not (because it would be a memcpy to const memory).
The cause of the problem: retro checks for hasAssignableElements, but then does
a move rather than an assignment.
https://github.com/dlang/phobos/pull/8721/files#diff-705ed5d9f4ea4f9dadcb07d7116df8dc8397e851639a28538dc0b1d6fa446f56L312-R318
Testcase (https://d.godbolt.org/z/z6KMY6nYf):
import std.range;
struct Handle {
int[5] entries;
void opAssign()(auto ref const(typeof(this)) that) const { }
}
const(Handle)[100] arr;
auto foo() {
return arr[0..5].retro;
}
the problem is fixed by reverting the lines for retro.
--
More information about the Digitalmars-d-bugs
mailing list