[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