[Issue 20965] Implicitly generated postblit overrides disabled copy ctor

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Nov 11 02:52:02 UTC 2020


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

--- Comment #4 from RazvanN <razvan.nitu1305 at gmail.com> ---
(In reply to Stanislav Blinov from comment #3)
> (In reply to RazvanN from comment #1)
> 
> > @disable this(this);
> > @disable this(ref typeof(this));
> > 
> > You don't have to reflect on any code this way.
> 
> If I don't want to further infest the codebase with postblits, I have to.
> 
> > The rule of thumb is: if you want to make sure that a posblit does not get
> > in your way you must defensively disable the postblit and then the copy
> > constructor will have priority.
> 
> Postblits will never go away then, until they stop compiling.

I agree, however, initially you start with tons of codebases that have postblit
and 0 that have copy constructor. The DIP [1] explicitly says:

"In order to assure a smooth transition from postblit to copy constructor, the
following strategy is employed: if a `struct` defines a postblit (user-defined
or generated) all copy constructor definitions will be ignored for that
particular `struct` and the postblit will be preferred. Existing code bases
that do not use the postblit may start using the copy constructor without any
problems, while codebases that rely on the postblit may start writing new code
using the copy constructor and remove the deprecated postblit from their code."

This was Walter's request and I don't think that this will change. 

[1]
https://github.com/dlang/DIPs/pull/129/files#diff-ecee0474c4314cd47dd8c2656b485c0cfd56e704a85de75839ec2850fb61f0ebR282

--


More information about the Digitalmars-d-bugs mailing list