• d-bugmail puremagic.com (56/56) Jun 21 2020 https://issues.dlang.org/show_bug.cgi?id=20965

d-bugmail puremagic.com writes:

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

          Issue ID: 20965
           Summary: Implicitly generated postblit overrides disabled copy
                    ctor
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: stanislav.blinov gmail.com

There's a bit of a contradiction in the spec. On one hand, it says [1]:

"When a copy constructor is defined for a struct, all implicit blitting is
disabled for that struct"

On the other [2]:

"WARNING: The postblit is considered legacy and is not recommended for new
code. Code should use copy constructors defined in the previous section. For
backward compatibility reasons, a struct that defines both a copy constructor
and a postblit will only use the postblit for implicit copying."

and

"...the compiler may generate ... postblit functions"

[1] https://dlang.org/spec/struct.html#struct-copy-constructor
[2] https://dlang.org/spec/struct.html#struct-postblit

What that results in in practice is that a generated postblit overrides copy
constructors. Consider:

struct C
{
    this(this) {}
}

struct S
{
    C c;
     disable this(ref typeof(this));
}

void main()
{
    S s1;
    auto s2 = s1; // problem
}

The line 'problem' compiles. I posit that it shouldn't. Alas:
- a copy ctor is present (and disabled), therefore implicit blitting should be
disabled, however
- C defines a postblit, therefore a postblit is implicitly generated for S,
therefore S "defines" both a copy ctor and a postblit after all, therefore only
the postblit is considered. Even though it is implicit and so should be
disabled :)

Consider that type C comes from elsewhere. Programmers that write new code,
ostensibly following advice from the WARNING cited above, shouldn't have to
manually introspect dependencies to find out whether they have postblits (that
is, if the whole point is to get rid of postblits). The language should make
the right call here, i.e. adhere to the first rule from the copy ctors spec:
disable all implicit blits (i.e. include generated postblits in that rule).

--