On Wednesday, September 12, 2018 5:55:05 PM MDT Nicholas Wilson via Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 23:36:11 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, September 12, 2018 5:17:44 PM MDT Nicholas Wilson
> >
> > via Digitalmars-d-announce wrote:
> >> it seems that even if we were to want to have @implicit as an opposite of C++'s explicit it would _always_ be present on copy-constructors which means that @implicit for copy constructors should itself be implicit.
> >
> > Oh, yes. The whole reason it's there is the fear that not requiring it would break code that currently declares a constructor that would be a copy constructor if we didn't require @implicit. So, if the DIP is accepted, you _could_ declare a constructor that should be a copy constructor but isn't, because it wasn't marked with @implicit (just like you can right now). If code breakage were not a concern, then there's pretty much no way that @implicit would be part of the DIP. Personally, I don't think that the risk of breakage is high enough for it to be worth requiring an attribute for what should be the normal behavior (especially when such a constructor almost certainly was intended to act like a copy constructor, albeit an explicit one), but Andrei doesn't agree.
>
> The bog-standard way of dealing with avoidable breakage with DIPs is a -dip-10xx flag. In this case, if set, would prefer to call copy constructors over blit + postblit.
>
> Also adding @implicit is a backwards incompatible change to a codebase that wants to use it as it will cause it to fail on older compilers.  Even if one does :
>
> static if (__VERSION__ < 2085) // or whenever it gets implemented
>       enum implicit;
> all over the place,

I don't disagree, but it's not my decision.

- Jonathan M Davis

On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis wrote:
> [snip]
> Personally, I'd rather that we just risk the code breakage caused by not having an attribute for copy constructors than use either @implicit or @copy, since it really only risks breaking code using constructors that were intended to be copy constructors but had to be called explicitly, and that code would almost certainly be fine if copy constructors then became implicit, but Andrei seems unwilling to do that. [snip]
> - Jonathan M Davis

I'd also vote for no attribute for copy constructors and have a tool to warn us of changes across compiler versions that can detect constructors that look like copy constructors.

If dub keeps track of the dmd compiler version we could even have automated warnings for all dub packages.

This would also start us on the road towards a tool that allows us to make breaking changes. At first the tool could just warn us. Then we could slowly add automated code transforms.

Pretty sure this sort of tool has been mentioned before. This seems like a good use-case.

R

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.

On Monday, September 17, 2018 7:30:24 AM MDT rmc via Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis
>
> wrote:
> > [snip]
> > Personally, I'd rather that we just risk the code breakage
> > caused by not having an attribute for copy constructors than
> > use either @implicit or @copy, since it really only risks
> > breaking code using constructors that were intended to be copy
> > constructors but had to be called explicitly, and that code
> > would almost certainly be fine if copy constructors then became
> > implicit, but Andrei seems unwilling to do that. [snip]
> > - Jonathan M Davis
>
> I'd also vote for no attribute for copy constructors and have a tool to warn us of changes across compiler versions that can detect constructors that look like copy constructors.
>
> If dub keeps track of the dmd compiler version we could even have automated warnings for all dub packages.
>
> This would also start us on the road towards a tool that allows us to make breaking changes. At first the tool could just warn us. Then we could slowly add automated code transforms.
>
> Pretty sure this sort of tool has been mentioned before. This seems like a good use-case.

At minimum, we could use a transitionary compiler flag like we have with other DIPs.

- Jonathan M Davis

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

On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis wrote:

> 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

Completely agree.

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

The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords?

-Alexander

On Monday, September 17, 2018 2:53:42 PM MDT 12345swordy 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
>
> The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords?

Every keyword that gets added is one more word that can't be used for identifiers, which we don't want to do without a really good reason, and in this particular context, I don't see what it would buy you anyway. You'd just end up not having to put @ in front of it - and then of course, that word couldn't be used as an identifier anymore. So, overall, going with a keyword over an attribute seems like a net negative.

IMHO, the core problem is that the DIP adds _anything_ that you have to mark up copy constructors with. We should just have a -dip* flag as a transition to deal with the theoretical breakage that @implicit is supposed to prevent (as well as gives us a chance to kick the tires of the implementation a bit first) and not do anything special to mark copy constructors aside from what their parameters are.

- Jonathan M Davis

On Mon, 17 Sep 2018 at 13:55, 12345swordy via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> 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
>
> The only thing I object is adding yet another attribute to a already big bag of attributes. What's wrong with adding keywords?
>
> -Alexander

I initially felt strongly against @implicit, it shouldn't be
necessary, and we could migrate without it.
But... assuming that @implicit should make an appearance anyway (it
should! being able to mark implicit constructors will fill a massive
usability hole in D!), then it doesn't hurt to use it eagerly here and
avoid a breaking change at this time, since it will be the correct
expression for the future regardless.

On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis wrote:
> 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

From what I've read, the copy constructor can be used with different types:

struct B
{
}

struct A
{
    @implicit this(ref B b)
    {
    }
}


B foo();

A a;
a = foo(); // ok because of @implicit
a = A(foo()); // ok without @implicit

That's why it exists, otherwise I wouldn't want two types to be implicitly convertible unless i explicitly tell it to be implicit.