Copy Constructor DIP and implementation

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Oct 11 08:49:50 UTC 2018


On Monday, October 8, 2018 4:27:47 AM MDT RazvanN via Digitalmars-d-announce 
wrote:
> On Monday, 8 October 2018 at 10:26:17 UTC, Nicholas Wilson wrote:
> > On Monday, 8 October 2018 at 10:14:51 UTC, RazvanN wrote:
> >> On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote:
> >>> Hi all,
> >>>
> >>> I just pushed another version of the DIP in which the major
> >>> modifications among otthers are removing implicit and use
> >>> copy constructor calls in all situations where a copy is
> >>> made. For more details, please visit [1] and if you have the
> >>> time, please offer some feedback,
> >>>
> >>> Thank you,
> >>> RazvanN
> >>>
> >>> [1] https://github.com/dlang/DIPs/pull/129/
> >>
> >> I've made all the changes in the code that the DIP includes[1]
> >> and the tests seem to be all green. I still need to add more
> >> tests; if you have any tests that you want to make sure the
> >> implementation takes into account please post them.
> >>
> >> Cheers,
> >> RazvanN
> >>
> >> [1] https://github.com/dlang/dmd/pull/8688
> >
> > Both the DIP and the implementation still lack a -dip10xx
> > switch.
>
> After discussing with Walter and Andrei we came to the conclusion
> that a flag is not necessary in this case. Immediately after the
> DIP is accepted, the postblit will be deprecated.

Even without a transitional switch, I would ask that we _please_ delay
actually deprecating postblit constructors until copy constructors have been
in at least one release. We do this when replacing old symbols in Phobos
with new ones, because if we don't, it's not possible to have your code
compile with the current release and master at the same time without getting
deprecation messages (while code _could_ use static if with __VERSION__ to
support multiple releases, that doesn't work with master, since
unfortunately, __VERSION__ on master always matches the most recent release
rather than the next one). The DIP that covers deprecations talks about
delaying deprecations when adding new symbols that for exactly that reason,
and replacing postblit constructors with copy constructors poses exactly the
same problem. It should always be possible to make code compile with both
master and the latest release without deprecation messages, since otherwise,
even programmers who are completely on top of things could end up having to
deal with a flood of deprecation messages that they can't fix.

- Jonathan M Davis





More information about the Digitalmars-d-announce mailing list