Copy Constructor DIP and implementation

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Sep 17 19:10:27 UTC 2018


On Monday, September 17, 2018 8:27:16 AM MDT Meta via Digitalmars-d-announce 
wrote:
> On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> > Hello everyone,
> >
> > I have finished writing the last details of the copy
> > constructor DIP[1] and also I have published the first
> > implementation [2]. As I wrongfully made a PR for the DIP queue
> > in the early stages of the development of the DIP, I want to
> > announce this way that the DIP is ready for the draft review
> > now. Those who are familiar with the compiler, please take a
> > look at the implementation and help me improve it!
> >
> > Thanks,
> > RazvanN
> >
> > [1] https://github.com/dlang/DIPs/pull/129
> > [2] https://github.com/dlang/dmd/pull/8688
>
> If @implicit is the contentious part of this DIP, maybe it would
> be a good idea for us to instead use a `pragma(copyCtor)` or the
> like to avoid having to add another attribute while preserving
> backward-compatibility. Like @implicit, it's very easy to turn
> existing constructors into copy constructors just by adding the
> pragma, and they can be added to code with impunity because even
> older versions of the compiler will just ignore pragmas they
> don't recognize.

Honestly, I don't think that using a pragma instead of an attribute fixes
much, and it goes against the idea of what pragmas are supposed to be for in
that pragmas are supposed to be compiler-specific, not really part of the
language.

The core problem is that no such attribute or pragma should be necessary in
the first place. It makes no sense to have a copy constructor that must be
called explicitly, and if we have to use an attribute (or pragma or anything
else) to optionally mark the copy constructor as a copy constructor, then
it's something that people are going to forget to do at least some portion
of the time, causing bugs. It also seems downright silly to have an
attribute (or pragma or whatever) that you have to _always_ use. No one is
going to be purposefully writing copy constructors that aren't "implicit."
So, they're _all_ going to have to have it. It would be like having to mark
all destructors with an attribute just so that they'd be treated as
destructors. It's something that's simply inviting bugs, because at least
some of the time, programmers will forget to use the attribute.

Basically, @implicit is being proposed out of fear that someone, somewhere
wrote a constructor that had what would be a copy constructor if D had them
instead of postblit constructors and that that code would break with the
DIP. Does anyone expect that such a constructor would be intended as
anything other than a copy constructor (albeit one that has to be called
explicitly)? And does anyone really think that such constructors are at all
common, given that the correct way to handle the problem in D right now is
the postblit constructor? We're talking about introducing an attribute that
should be unnecessary, which will be annoying to use, and which will be
error-prone given the bugs that you'll get if you forget to mark your copy
constructor with it. And it's all to avoid breaking a theoretical piece of
code that I would think that we could all agree is extremely rare if it
exists in any real D code base at all. Simply using a transitional compiler
switch like we have with other DIPs would make _way_ more sense than
burdening the language with an unnecessary attribute that's just going to
make it easier to write buggy code. This is clearly a case of making the
language worse long term in order to avoid a theoretical problem in the
short term.

- Jonathan M Davis





More information about the Digitalmars-d-announce mailing list