https://issues.dlang.org/show_bug.cgi?id=20965
--- Comment #4 from RazvanN <[email protected]> --- (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 --
