www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Copy Constructor DIP and implementation

reply RazvanN <razvan.nitu1305 gmail.com> writes:
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
Sep 11
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/09/2018 3:08 AM, 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
Here is a question (that I don't think has been asked) why not copy? copy this(ref Foo other) { } It can be read as copy constructor, which would be excellent for helping people learn what it is doing (spec lookup). Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other);
Sep 11
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole 
wrote:
 Here is a question (that I don't think has been asked) why not 
  copy?
It's not wrong to call this an implicit constructor since it's called implicitly. It also means that, if we get implicit constructors in general, we can keep the same syntax and annotations, and it will be consistent.
 Also can we really not come up with an alternative bit of code 
 than the tupleof to copying wholesale? E.g. super(other);
That would be possible, but it would be inconsistent with super constructors in general.
Sep 11
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole 
wrote:
 Here is a question (that I don't think has been asked) why not 
  copy?

  copy this(ref Foo other) { }

 It can be read as copy constructor, which would be excellent 
 for helping people learn what it is doing (spec lookup).

 Also can we really not come up with an alternative bit of code 
 than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. implicit can mean many things, while copy is much more specific... For what is worth I vote for copy ! :)
Sep 12
next sibling parent reply Elie Morisse <syniurge gmail.com> writes:
On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic 
wrote:
 On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole 
 wrote:
 Here is a question (that I don't think has been asked) why not 
  copy?

  copy this(ref Foo other) { }

 It can be read as copy constructor, which would be excellent 
 for helping people learn what it is doing (spec lookup).

 Also can we really not come up with an alternative bit of code 
 than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. implicit can mean many things, while copy is much more specific... For what is worth I vote for copy ! :)
implicit makes sense if extending explicitly implicit calls to all other constructors gets somday considered. Some people argued for it and I agree with them that it'd be nice to have, for ex. to make a custom string struct type usable without having to smear the code with constructor calls.
Sep 12
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 12, 2018 10:04:57 AM MDT Elie Morisse via 
Digitalmars-d-announce wrote:
 On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic

 wrote:
 On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole

 wrote:
 Here is a question (that I don't think has been asked) why not
  copy?

  copy this(ref Foo other) { }

 It can be read as copy constructor, which would be excellent
 for helping people learn what it is doing (spec lookup).

 Also can we really not come up with an alternative bit of code
 than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. implicit can mean many things, while copy is much more specific... For what is worth I vote for copy ! :)
implicit makes sense if extending explicitly implicit calls to all other constructors gets somday considered. Some people argued for it and I agree with them that it'd be nice to have, for ex. to make a custom string struct type usable without having to smear the code with constructor calls.
That's why some argued in a previous thread on the topic that we should decide what (if anything) we're going to do with adding implicit construction to the language before finalizing this DIP. If we added some sort of implicit constructor to the language, then implicit would make some sense on copy constructors (it's still a bit weird IMHO, but it does make some sense when explained), and in that case, having used copy could actually be a problem. If we're looking at this as an attribute that's purely going to be used on copy constructors, then copy does make more sense, but it's also less flexible. implicit could potentially be used for more, whereas copy really couldn't - not when it literally means copy constructor. 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. But at least, when start arguing about that, fact that the work "explicitly" very naturally fits into that as the description for what a copy constructor would be currently, it does make more sense that implicit would be used. Ultimately, I expect that if we add any attribute for this, people coming to D are going to think that it's downright weird, but if we're going to have one, if we go with implicit, we're future-proofing things a bit, and personally, thinking about it over time, I've found that it feels less like a hack than something like copy would. If we had copy, this would clearly forever be something that we added just because we has postblit constructors first, whereas implicit at least _might_ be used for something more. It would still feel weird and hacky if it never was used for anything more, but at least we'd be future-proofing the language a bit, and implicit does make _some_ sense after it's explained, even if very few people (if any) will initially think that it makes sense. - Jonathan M Davis
Sep 12
next sibling parent reply Gary Willoughby <dev nomad.uk.net> writes:
On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis 
wrote:
 Ultimately, I expect that if we add any attribute for this, 
 people coming to D are going to think that it's downright 
 weird, but if we're going to have one, if we go with  implicit, 
 we're future-proofing things a bit, and personally, thinking 
 about it over time, I've found that it feels less like a hack 
 than something like  copy would. If we had  copy, this would 
 clearly forever be something that we added just because we has 
 postblit constructors first, whereas  implicit at least _might_ 
 be used for something more.
That does actually make a lot of sense. Isn't there any way these constructors could be inferred without the attribute?
Sep 12
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 12, 2018 1:18:11 PM MDT Gary Willoughby via 
Digitalmars-d-announce wrote:
 On Wednesday, 12 September 2018 at 16:40:45 UTC, Jonathan M Davis

 wrote:
 Ultimately, I expect that if we add any attribute for this,
 people coming to D are going to think that it's downright
 weird, but if we're going to have one, if we go with  implicit,
 we're future-proofing things a bit, and personally, thinking
 about it over time, I've found that it feels less like a hack
 than something like  copy would. If we had  copy, this would
 clearly forever be something that we added just because we has
 postblit constructors first, whereas  implicit at least _might_
 be used for something more.
That does actually make a lot of sense. Isn't there any way these constructors could be inferred without the attribute?
As I understand it, the entire point of the attribute is to avoid any breakage related to constructors that have a signature that matches what a copy constructor would be. If we didn't care about that, there would be no reason to have an attribute. Personally, I think that the concerns about such possible breakage are overblown, because it really wouldn't make sense to declare a constructor with the signature of a copy constructor unless you intended to use it as one (though right now, it would have to be called explicitly). And such code shouldn't break if "explicit" copy constructors then become "implicit" copy constructors automatically. However, Andrei does not believe that the risk is worth it and insists that we need a way to differentiate between the new copy constructors and any existing constructors that happen to look like them. So, there won't be any kind inference here. If we were going to do that, we wouldn't be adding the attribute in the first place. - Jonathan M Davis
Sep 12
parent scroodge <scroodge evil.dot> writes:
On Wednesday, 12 September 2018 at 19:39:21 UTC, Jonathan M Davis 
wrote:
 However, Andrei does not believe that the risk is worth it and 
 insists that we need a way to differentiate between the new 
 copy constructors and any existing constructors that happen to 
 look like them. So, there won't be any kind inference here. If 
 we were going to do that, we wouldn't be adding the attribute 
 in the first place.
Andrei has a bad score in understanding what is best for language. It's too arrogant, or scary, to listen to anyone: that's about this ... https://www.youtube.com/watch?v=KAWA1DuvCnQ For mockery, I would like to point out that the speaker of this proposal has also exchanged "nogc" for " nogc": throw the fears into the sea, and fix the total nonsense that this language has become. Best wishes to the moderator.
Sep 12
prev sibling parent reply rmc <rjmcguire gmail.com> writes:
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
Sep 17
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 17
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
 wrote:
 Here is a question (that I don't think has been asked) why not
  copy?

  copy this(ref Foo other) { }

 It can be read as copy constructor, which would be excellent
 for helping people learn what it is doing (spec lookup).

 Also can we really not come up with an alternative bit of code
 than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. implicit can mean many things, while copy is much more specific... For what is worth I vote for copy ! :)
implicit may be attributed to any constructor allowing it to be invoked implicitly. It's the inverse of C++'s `explicit` keyword. As such, implicit is overwhelmingly useful in its own right. This will address my single biggest usability complaint of D as compared to C++. implicit is super awesome, and we must embrace it.
Sep 12
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 12 September 2018 at 22:11:20 UTC, Manu wrote:
 On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:
 On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki 
 cattermole wrote:
 Here is a question (that I don't think has been asked) why 
 not
  copy?

  copy this(ref Foo other) { }

 It can be read as copy constructor, which would be excellent 
 for helping people learn what it is doing (spec lookup).

 Also can we really not come up with an alternative bit of 
 code than the tupleof to copying wholesale? E.g. 
 super(other);
I could not agree more. implicit can mean many things, while copy is much more specific... For what is worth I vote for copy ! :)
implicit may be attributed to any constructor allowing it to be invoked implicitly. It's the inverse of C++'s `explicit` keyword. As such, implicit is overwhelmingly useful in its own right. This will address my single biggest usability complaint of D as compared to C++. implicit is super awesome, and we must embrace it.
https://stackoverflow.com/a/11480555/1112970
I have no idea why you would want to declare a copy-constructor 
as explicit
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. From what I understand of explicit in C++, if we were to have implicit construction it would be used for things like struct Foo { implicit this(int) {} } void useFoo(Foo f) { ... } void main() { useFoo(0); // Fine, implicitly construct auto tmp = Foo(0); useFoo(tmp); } If at some point in the future we decide that we do want to add implicit construction, then we can make the copy constructor always implicit. Until that point I see no need for this, because it is replacing postblit which is always called implicitly. \all please remember to leave feedback on the actual draft review on the DIP PR.
Sep 12
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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.
 If at some point in the future we decide that we do want to add
  implicit construction, then we can make the copy constructor
 always  implicit. Until that point I see no need for this,
 because it is replacing postblit which is always called
 implicitly.
Except that the whole reason that implicit is being added is to avoid the risk of breaking code, and that problem really isn't going to go away. So, it's hard to see how we would ever be able to remove it. Certainly, if we were willing to take the risks associated with it, there wouldn't be any reason to introduce implicit in the first place (at least not for copy constructors). If it were my decision, I wouldn't introduce implicit and would risk the code breakage (which I would expect to be pretty much non-existent much as it theoretically could happen), but it's not my decision. - Jonathan M Davis
Sep 12
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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,
 It is illegal to declare a copy constructor for a struct that 
 has a postblit defined and vice versa:
Sep 12
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 12 September 2018 at 23:55:05 UTC, Nicholas Wilson 
wrote:
 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,

 It is illegal to declare a copy constructor for a struct that 
 has a postblit defined and vice versa:
Hmm, I suppose one could static if (__VERSION__ < 2085) // use a postblit else // use a copy ctor.
Sep 12
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 12
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 12, 2018 4:11:20 PM MDT Manu via Digitalmars-d-
announce wrote:
 On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via Digitalmars-d-announce

 <digitalmars-d-announce puremagic.com> wrote:
 On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole

 wrote:
 Here is a question (that I don't think has been asked) why not
  copy?

  copy this(ref Foo other) { }

 It can be read as copy constructor, which would be excellent
 for helping people learn what it is doing (spec lookup).

 Also can we really not come up with an alternative bit of code
 than the tupleof to copying wholesale? E.g. super(other);
I could not agree more. implicit can mean many things, while copy is much more specific... For what is worth I vote for copy ! :)
implicit may be attributed to any constructor allowing it to be invoked implicitly. It's the inverse of C++'s `explicit` keyword. As such, implicit is overwhelmingly useful in its own right. This will address my single biggest usability complaint of D as compared to C++. implicit is super awesome, and we must embrace it.
Except that this DIP doesn't do anything of the sort. It specifically only affects copy constructors. Yes, in theory, we could later extend implicit to do something like what you describe, but there are not currently any plans to do so. So, implicit makes more sense than copy in the sense that it's more likely to be forward-compatible (or at least, implicit could be reused in a sensible manner, whereas copy couldn't be; so, if we used copy, we might also have to introduce implicit later anyway), but either way, saying that implicit has anything to do with adding implicit construction to D like C++ has is currently false. In fact, the DIP specifically makes it an error to use implicit on anything other than a copy constructor. - Jonathan M Davis
Sep 12
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/11/2018 8:08 AM, RazvanN wrote:
 [1] https://github.com/dlang/DIPs/pull/129
 [2] https://github.com/dlang/dmd/pull/8688
Thank you, RazvanN!
Sep 11
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 11 September 2018 at 23:56:56 UTC, Walter Bright 
wrote:
 On 9/11/2018 8:08 AM, RazvanN wrote:
 [1] https://github.com/dlang/DIPs/pull/129
 [2] https://github.com/dlang/dmd/pull/8688
Thank you, RazvanN!
I very much agree!
Sep 12
prev sibling next sibling parent Gary Willoughby <dev nomad.uk.net> writes:
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
I'm not sure about the naming of ` implicit` attribute. It seems confusing when used. ` copy` feels more natural or do we even need a new attribute at all?
Sep 12
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Sep 11, 2018 at 03:08:33PM +0000, RazvanN via Digitalmars-d-announce
wrote:
 I have finished writing the last details of the copy constructor
 DIP[1] and also I have published the first implementation [2].
[...] Here are some comments: - The DIP should address what implicit means when applied to a function that isn't a ctor. Either it should be made illegal, or the spec should clearly state that it's ignored. - I prefer the former option, because that minimizes the risk of conflicts in the future if we were to expand the scope of implicit to other language constructs. - However, the latter option is safer in that if existing user code uses implicit with a different meaning, the first option would cause code breakage and require the user to replace all uses of implicit with something else. - The DIP needs to address what a copy ctor might mean in a situation with unions, and/or whether it's legal to use unions with copy ctors. There are a few important cases to consider (there may be others): - Should copy ctors even be allowed in unions? - The copy ctor is defined in the union itself. - The union contains fields that have copy ctors. If two overlapping fields have copy ctors, which ctor will get called? Should this case be allowed, or made illegal? - How would type qualifiers (const, immutable, etc.) interact with unions of the above two cases? - If a struct contains a union, and another non-union field that has a copy ctor, how should the compiler define the generated copy ctor of the outer struct? - If a struct declares only one copy ctor, say mutable -> mutable, then according to the DIP (under the section "copy constructor call vs. standard copying (memcpy)"), declaring an immutable variable of that type will default to standard copying instead. - This means if the struct needs explicit handling of copying in a copy ctor, the user must remember to write all overloads of the copy ctor, otherwise there will be cases where standard copying is silently employed, bypassing any user-defined semantics that may be necessary for correct copying. - Shouldn't there be a way for the compiler to automatically generate this boilerplate code instead? Should there be a way to optionally generate warnings in such cases, so that the user can be aware in case default copying isn't desired? - What should happen if the user declares a copy ctor as a template function? Should the compiler automatically use that template to generate const/immutable/etc. copy ctors when needed? T -- Change is inevitable, except from a vending machine.
Sep 12
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
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.
Sep 17
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 17
next sibling parent shfit <shfit fake.de> writes:
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.
Sep 17
prev sibling next sibling parent reply tide <tide tide.tide> writes:
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.
Sep 17
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, September 17, 2018 5:14:28 PM MDT tide via Digitalmars-d-announce 
wrote:
 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.
No. That wouldn't be a copy constructor. The DIP specifically says that "A declaration is a copy constructor declaration if it is a constructor declaration annotated with the implicit attribute and takes only one parameter by reference that is of the same type as typeof(this)." So, it clearly must be the same type and can't be a different type. It also says that "The copy constructor needs to be annotated with implicit in order to distinguish a copy constructor from a normal constructor and avoid silent modification of code behavior." Andrei confirmed that that's why implicit was there in the last major discussion on the DIP in the newsgroup. So, it's clearly there in order to avoid breaking existing code - code which is going to be _extremely_ rare. - Jonathan M Davis
Sep 17
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 17 September 2018 at 23:14:28 UTC, tide wrote:
 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.
This DIP does not allow this, but apparently it is on the horizon[1],
  it will be easier to extend the feature to copy construct 
 from any type to any type
Is this a thing we are even considering?
Yes.
I don't agree with it. [1]: https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Sep 17
prev sibling parent Johannes Loher <johannes.loher fg4f.de> writes:
On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis 
wrote:
 On Monday, September 17, 2018 8:27:16 AM MDT Meta via 
 Digitalmars-d-announce wrote:
 [...]
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. [...]
I totally agree with this.
Sep 22
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Sep 17
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 17
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Sep 17
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 17 September 2018 at 23:07:22 UTC, Manu wrote:
 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.
If that where the case, then why not make it an actual keyword? A frequent complaint regarding D is that there are too many attributes, this will undoubtedly adding more to it. -Alexander
Sep 22
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 22 September 2018 at 17:43:57 UTC, 12345swordy wrote:
 If that where the case, then why not make it an actual keyword? 
 A frequent complaint regarding D is that there are too many 
 attributes, this will undoubtedly adding more to it.
When I (and surely others like me) complain that there are too many attributes, the complaint has nothing to do with the character. I consider "nothrow" and "pure" to be part of the problem and they lack .
Sep 22
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe via 
Digitalmars-d-announce wrote:
 On Saturday, 22 September 2018 at 17:43:57 UTC, 12345swordy wrote:
 If that where the case, then why not make it an actual keyword?
 A frequent complaint regarding D is that there are too many
 attributes, this will undoubtedly adding more to it.
When I (and surely others like me) complain that there are too many attributes, the complaint has nothing to do with the character. I consider "nothrow" and "pure" to be part of the problem and they lack .
Yeah, the problem has to do with how much you have to mark up your code. Whether you have foo bar baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse. In addition, most of the complaints about implicit have to do with the fact that it doesn't even add anything. It's annoying that we have nogc, safe, pure, etc. but at least each of those adds something. implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist. - Jonathan M Davis
Sep 22
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis 
wrote:
 On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe 
 via Digitalmars-d-announce wrote:
 [...]
Yeah, the problem has to do with how much you have to mark up your code. Whether you have foo bar baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse. In addition, most of the complaints about implicit have to do with the fact that it doesn't even add anything. It's annoying that we have nogc, safe, pure, etc. but at least each of those adds something. implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist. - Jonathan M Davis
It appears that implicit has been removed from the implementation [1], but not yet from the DIP. https://github.com/dlang/dmd/commit/cdd8100
Sep 22
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 22, 2018 8:40:15 PM MDT Nicholas Wilson via 
Digitalmars-d-announce wrote:
 On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis

 wrote:
 On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe

 via Digitalmars-d-announce wrote:
 [...]
Yeah, the problem has to do with how much you have to mark up your code. Whether you have foo bar baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse. In addition, most of the complaints about implicit have to do with the fact that it doesn't even add anything. It's annoying that we have nogc, safe, pure, etc. but at least each of those adds something. implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist. - Jonathan M Davis
It appears that implicit has been removed from the implementation [1], but not yet from the DIP. https://github.com/dlang/dmd/commit/cdd8100
Well, that's a good sign. - Jonathan M Davis
Sep 22
prev sibling parent reply Gary Willoughby <dev nomad.uk.net> writes:
On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson 
wrote:
 It appears that  implicit has been removed from the 
 implementation [1], but not yet from the DIP.

 https://github.com/dlang/dmd/commit/cdd8100
Good, It's not needed.
Sep 24
parent reply Manu <turkeyman gmail.com> writes:
On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
 wrote:
 It appears that  implicit has been removed from the
 implementation [1], but not yet from the DIP.

 https://github.com/dlang/dmd/commit/cdd8100
Good, It's not needed.
implicit is desperately needed (just not for copy constructors!). Do you have confidence that an implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support implicit's introduction.
Sep 24
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
 On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:
 On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson 
 wrote:
 It appears that  implicit has been removed from the 
 implementation [1], but not yet from the DIP.

 https://github.com/dlang/dmd/commit/cdd8100
Good, It's not needed.
implicit is desperately needed (just not for copy constructors!). Do you have confidence that an implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support implicit's introduction.
If we are going to introduce the keyword/attribute implicit then it needs its own DIP. As of now, this DIP have a very weak justification for it. -Alex
Sep 24
next sibling parent Manu <turkeyman gmail.com> writes:
On Mon, 24 Sep 2018 at 12:40, 12345swordy via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On Monday, 24 September 2018 at 17:34:58 UTC, Manu wrote:
 On Mon, 24 Sep 2018 at 00:55, Gary Willoughby via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com>
 wrote:
 On Sunday, 23 September 2018 at 02:40:15 UTC, Nicholas Wilson
 wrote:
 It appears that  implicit has been removed from the
 implementation [1], but not yet from the DIP.

 https://github.com/dlang/dmd/commit/cdd8100
Good, It's not needed.
implicit is desperately needed (just not for copy constructors!). Do you have confidence that an implicit proposal will happen if you all insist that it's removed here? This is a great driving motivator to support implicit's introduction.
If we are going to introduce the keyword/attribute implicit then it needs its own DIP. As of now, this DIP have a very weak justification for it.
I certainly agree; I'm fairly sure I produced the very first critical comment on this issue when it first landed, which went like " implicit is a dependency and needs a dependent dip", which Andrei brushed off. I still believe it's a separate feature, and it's a dependency for this particular DIP, so that should come first... but here's the thing; that's just not how dlang works around here. We like the idea that there's process and structure, but there's not, and you just need to be practical about maneuvering towards the goals you want in the ways that manifest. In this case, having implicit is a very real and desirable goal, it's been a sore hole in the language since ever... so anything that moves it towards reality is preferable to nothing. While I felt strongly about my conviction initially (that there should be a dependent DIP), I realised that a much more useful and practical position was to allow this dip to introduce implicit implicitly (heh)... that's a much better reality than waiting an addition year or 2 (if ever!) for the thing otherwise. I encourage people to consider this holistically and consider the practicality of allowing it, even thought it's not a strictly principled in terms of process ;) copy-ctor is good, implicit is also good... we want both. Even though copy-ctor is not strictly dependent on implicit, allowing it will satisfy that there's not a breaking change, it it will also self-justify expansion of implicit as intended without a separate and time-consuming fight, which is actually the true value of this DIP!
Sep 24
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, September 24, 2018 3:20:28 PM MDT Manu via Digitalmars-d-announce 
wrote:
 copy-ctor is good,  implicit is also good... we want both. Even though
 copy-ctor is not strictly dependent on  implicit, allowing it will
 satisfy that there's not a breaking change, it it will also
 self-justify expansion of  implicit as intended without a separate and
 time-consuming fight, which is actually the true value of this DIP!
implicit on copy constructors is outright bad. It would just be a source of bugs. Every time that someone forgets to use it (which plenty of programmers will forget, just like they forget to use safe, pure, nothrow, etc.), they're going to have a bug in their program. However, unlike, with attributes like safe or pure, they're not going to get a compiler error in their program; they're going to get a logic error. They may or may not find that bug quickly, but the compiler isn't going to point it out to them. And if implicit weren't a thing, then the problem wouldn't even exist. implicit is trying to get around breaking an extremely unlikely piece of code which would be far better fixed by using a transitional compiler flag and which adds _no_ value for copy constructors in the long run. Even if we do later add implicit to the language for regular constructors, it has no business on copy constructors. And its value on other constructors needs to be evaluated and examined on its own separately from the issue of copy constructors. We should not be letting implicit be put onto copy constructors just to get it into the language. If it's such a valuable feature on regular constructors, it should be able to get in on a separate DIP specifically for that purpose without piggybacking in on the copy constructor DIP - especially when it's clearly going to be a source of bugs if it's required to be on copy constructors. And it just needlessly adds to the attribute soup. At least if it were added for regular constructors, it would be adding value. For copy constructors, it's just adding annoyance and the risk of bugs. - Jonathan M Davis
Sep 24
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis 
wrote:
  implicit on copy constructors is outright bad. It would just 
 be a source of bugs. Every time that someone forgets to use it 
 (which plenty of programmers will forget, just like they forget 
 to use  safe, pure, nothrow, etc.), they're going to have a bug 
 in their program. However, unlike, with attributes like  safe 
 or pure, they're not going to get a compiler error in their 
 program; they're going to get a logic error. They may or may 
 not find that bug quickly, but the compiler isn't going to 
 point it out to them.
I think this is the most important reason. In C++, where everything is implicit by default (which is bad) and (I think) you are encouraged to use explicit where possible, you should never use it for the copy constructor because the compiler always calls it implicitly for you and is the whole point of having: Foo a; Foo b = a; do something useful. Putting explicit on the copy ctor means that no longer works, one can then only use it with Foo a; Foo b(a); Having `Foo a; Foo b = a;` do something completely different by the addition or removal of one attribute is a serious problem just waiting to happen.
Sep 24
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, September 24, 2018 7:59:36 PM MDT Nicholas Wilson via 
Digitalmars-d-announce wrote:
 On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis

 wrote:
  implicit on copy constructors is outright bad. It would just
 be a source of bugs. Every time that someone forgets to use it
 (which plenty of programmers will forget, just like they forget
 to use  safe, pure, nothrow, etc.), they're going to have a bug
 in their program. However, unlike, with attributes like  safe
 or pure, they're not going to get a compiler error in their
 program; they're going to get a logic error. They may or may
 not find that bug quickly, but the compiler isn't going to
 point it out to them.
I think this is the most important reason. In C++, where everything is implicit by default (which is bad) and (I think) you are encouraged to use explicit where possible, you should never use it for the copy constructor because the compiler always calls it implicitly for you and is the whole point of having: Foo a; Foo b = a; do something useful. Putting explicit on the copy ctor means that no longer works, one can then only use it with Foo a; Foo b(a); Having `Foo a; Foo b = a;` do something completely different by the addition or removal of one attribute is a serious problem just waiting to happen.
The key thing with explicit in C++ is to avoid issues with implicit conversions between types. You can get weird junk like where int foo(string s); foo(42); compiles, because you have a type A with an implicit constructor which takes int, and an implicit conversion to string. Even though A isn't explicitly used here anywhere, because it's available, and no more than three conversions are required to go from int to string when using A, the compiler will use A to from int to string. That probably isn't what the programmer wanted, but the compiler will happily do it. Because of this, it's best practice in C++ to put explicit on any constructors which take other types where you don't explicitly want the implicit conversion in order to try to avoid this conversion mess. You then only leave explicit off of constructors where you want the implicit conversion or constructors where it's unnecessary (e.g. default constructors or copy constructors). D avoids this mess by simply not having any kind of implicit construction. It just has implicit conversion via alias this. It may or may not be worth adding implicit construction via something like implicit, but it would at least then only be on constructors which were explicitly marked with implicit, whereas with C++, you have to use explicit to turn off the behavior. So, in C++, it's a total mess by default, whereas in D, we'd only have it where the programmer asked for it. And presumably, any DIP that added it wouldn't have the compiler do more than one conversion at a time, whereas as I understand it, C++ allows the compiler to do up to three conversions in order to make a piece of code work. But ultimately, such details will have to be decided with such a DIP. Either way, none of this has anything to do with copy constructors. It makes no sense to have copy constructors that require that you call them explicitly. And while it would be bad enough if the DIP required that you mark copy constructors with implicit for them to work as copy constructors and then didn't have implicit copying without implicit, that's not what it does. Instead, what it does when you forget implicit is revert to the default copy semantics, meaning that you have a copy constructor that needs to be called explicitly, but you didn't realize that it needed to be called explicitly, and you're blindly using the default copy semantics rather than the copy constructor. So, the semantics that the DIP describes are just plain a recipe for bugs. But since the PR has been updated to remove implicit, maybe the DIP will be updated to remove it as well, and the whole implicit discussion can be left to a future DIP on implicit construction and left out of copy construction entirely. - Jonathan M Davis
Sep 24
prev sibling parent Manu <turkeyman gmail.com> writes:
On Mon, 24 Sep 2018 at 16:22, Jonathan M Davis via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On Monday, September 24, 2018 3:20:28 PM MDT Manu via Digitalmars-d-announce
 wrote:
 copy-ctor is good,  implicit is also good... we want both. Even though
 copy-ctor is not strictly dependent on  implicit, allowing it will
 satisfy that there's not a breaking change, it it will also
 self-justify expansion of  implicit as intended without a separate and
 time-consuming fight, which is actually the true value of this DIP!
implicit on copy constructors is outright bad. It would just be a source of bugs. Every time that someone forgets to use it (which plenty of programmers will forget, just like they forget to use safe, pure, nothrow, etc.), they're going to have a bug in their program.
perhaps a rule where declaring a copy-ctor WITHOUT explicit emits a compile error...?
Sep 24
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis 
wrote:
  implicit is just there because of the fear of breaking a 
 theoretical piece of code that's going to be extremely rare if 
 it exists at all and in most cases would continue to work just 
 fine even if it did exist.

 - Jonathan M Davis
I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.
Sep 24
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, September 24, 2018 10:44:01 AM MDT Meta via Digitalmars-d-
announce wrote:
 On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis

 wrote:
  implicit is just there because of the fear of breaking a
 theoretical piece of code that's going to be extremely rare if
 it exists at all and in most cases would continue to work just
 fine even if it did exist.

 - Jonathan M Davis
I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.
In this particular case, a transitional compiler flag like we've done with other DIPs makes _far_ more sense than forcing everyone to use an attribute forever - especially when forgetting to use the attribute is going to be a further source of bugs, one which would _easily_ outweigh any code breakage caused by not having the attribute. But having a transitional compiler flag would give us a way to deal with the potential code breakage if it exists. - Jonathan M Davis
Sep 24
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, September 17, 2018 5:07:22 PM MDT Manu via Digitalmars-d-announce 
wrote:
 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.
Except that implicit could be introduced for other constructors without having it on copy constructors, and the fact that copy constructors will require it is just going to cause bugs, because plenty of folks are going to forget to use it and end up with the default copying behavior instead of their custom copy constructor being used. Good testing should find that pretty quickly, but it's almost certainly going to be a common bug, and it has no need to exist. It's all there in order to avoid breaking code that's likely only theoretical and not something that actual D code bases have done. And if there is a stray code base that did it, it's certainly going to be in the extreme minority, and the code will almost certainly work as a proper copy constructor anyway, since that's pretty much the only reason to write such a constructor. So, we'd be trying to avoid breaking very rare code by introducing a feature that will definitely cause bugs. IMHO, it would be _far_ better to just use a transitional -dip* compiler flag like we have with other DIPs. It would also give us the benefit of being able to bang on the implementation a bit before making it the normal behavior. We can still add implicit to other constructors for implicit construction with a later DIP (assuming that Walter and Andrei could be convinced of it). I don't see how having it on copy constructors really helps with that. It just means that the attribute would already be there, not that it would necessarily ever be used for what you want, and _not_ having it on copy constructors wouldn't prevent it from being used for implicit construction if such a DIP were ever accepted. So, while I understand that you want implicit construction, I think that it's a huge mistake to tie that up into copy constructors, particularly since it really doesn't make sense to have copy constructors that aren't implicit, and having implicit for copy constructiors is going to cause bugs when it's forgotten. - Jonathan M Davis
Sep 17
parent reply aliak <something something.com> writes:
On Monday, 17 September 2018 at 23:32:39 UTC, Jonathan M Davis 
wrote:
 On Monday, September 17, 2018 5:07:22 PM MDT Manu via 
 Digitalmars-d-announce wrote:
 [...]
Except that implicit could be introduced for other constructors without having it on copy constructors, and the fact that copy constructors will require it is just going to cause bugs, because plenty of folks are going to forget to use it and end up with the default copying behavior instead of their custom copy constructor being used. Good testing should find that pretty quickly, but it's almost certainly going to be a common bug, and it has no need to exist. It's all there in order to avoid breaking code that's likely only theoretical and not something that actual D code bases have done. And if there is a stray code base that did it, it's certainly going to be in the extreme minority, and the code will almost certainly work as a proper copy constructor anyway, since that's pretty much the only reason to write such a constructor. So, we'd be trying to avoid breaking very rare code by introducing a feature that will definitely cause bugs. IMHO, it would be _far_ better to just use a transitional -dip* compiler flag like we have with other DIPs. It would also give us the benefit of being able to bang on the implementation a bit before making it the normal behavior. We can still add implicit to other constructors for implicit construction with a later DIP (assuming that Walter and Andrei could be convinced of it). I don't see how having it on copy constructors really helps with that. It just means that the attribute would already be there, not that it would necessarily ever be used for what you want, and _not_ having it on copy constructors wouldn't prevent it from being used for implicit construction if such a DIP were ever accepted. So, while I understand that you want implicit construction, I think that it's a huge mistake to tie that up into copy constructors, particularly since it really doesn't make sense to have copy constructors that aren't implicit, and having implicit for copy constructiors is going to cause bugs when it's forgotten. - Jonathan M Davis
I think this can be made in to a compiler error. The logic would be if there is any copy constructor defined (by copy constructor I mean a constructor that gets passed an object that can be used to construct typeof(this) - so ignore definition in DIP), then default copy construction is a compiler error unless an implicit copy constructor is defined. struct A { this(ref A) {} } A a; A b = a; // error, cannot implicitly copy because an explicit one is provided A c = A(a); // ok This will break compilation of current code that has an explicit copy constructor, and the fix is simply to add the attribute implicit.
Sep 18
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via Digitalmars-d-
announce wrote:
 This will break compilation of current code that has an explicit
 copy constructor, and the fix is simply to add the attribute
  implicit.
In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis
Sep 18
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis 
wrote:
 On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via 
 Digitalmars-d- announce wrote:
 This will break compilation of current code that has an 
 explicit copy constructor, and the fix is simply to add the 
 attribute  implicit.
In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis
Apparently because extending copy constructors are intended to be extended to types other than typeof(this), which would also be implicit, and then implicit is to make sure that you actually want this(ref SomethingElse){ ... } to be implicitly called when A a; B b; ... b = a; which I think is a bad idea, not the least of which is because thats what opAssign is for. See https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Sep 18
prev sibling next sibling parent aliak <something something.com> writes:
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis 
wrote:
 On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via 
 Digitalmars-d- announce wrote:
 This will break compilation of current code that has an 
 explicit copy constructor, and the fix is simply to add the 
 attribute  implicit.
In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis
Well one breaks compilation and the other is silent code changes. And No.compilerSwitch > Yes.compilerSwitch when possible. I'm actually not strongly for implicit btw.
Sep 18
prev sibling parent rmc <rjmcguire gmail.com> writes:
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis 
wrote:
 On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via 
 Digitalmars-d- announce wrote:
 This will break compilation of current code that has an 
 explicit copy constructor, and the fix is simply to add the 
 attribute  implicit.
In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis
What about a command-line switch that just detects copy constructors? LLVM 8 supposedly has a new feature which breaks compatibility for casts from float -> int: Floating-point casts—converting a floating point number to an integer by discarding the data after the decimal—has been optimized, but in a way that might cause problems for developers who rely on undefined behavior around this feature. Clang has a new command-line switch to detect this issue. Could we do copy-constructors in a similar way?
Sep 21
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, September 24, 2018 9:33:19 PM MDT Manu via Digitalmars-d-announce 
wrote:
 On Mon, 24 Sep 2018 at 16:22, Jonathan M Davis via

 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
 On Monday, September 24, 2018 3:20:28 PM MDT Manu via
 Digitalmars-d-announce>
 wrote:
 copy-ctor is good,  implicit is also good... we want both. Even though
 copy-ctor is not strictly dependent on  implicit, allowing it will
 satisfy that there's not a breaking change, it it will also
 self-justify expansion of  implicit as intended without a separate and
 time-consuming fight, which is actually the true value of this DIP!
implicit on copy constructors is outright bad. It would just be a source of bugs. Every time that someone forgets to use it (which plenty of programmers will forget, just like they forget to use safe, pure, nothrow, etc.), they're going to have a bug in their program.
perhaps a rule where declaring a copy-ctor WITHOUT explicit emits a compile error...?
That would pretty much defeat the whole purpose of why implicit was added to the DIP in the first place. It's just that it would turn the feared silent code breakage into a compiler error. So, I suppose that it would be an improvement, but it's the sort of thing that would have to go behind a transitional compiler switch, and as soon as we do that, why have implicit on copy constructors at all? It makes far more sense to use a transitional compiler switch to simply sort out the problem with the potential (but highly unlikely) silent breakage and not do anything with implicit with copy constructors whatsoever. It avoids having to put a useless attribute on copy constructors forever, and it avoids any potential bugs. Then we can have a separate DIP that deals with implicit and non-copy constructors for implicit construction. And maybe we do ultimately end up with implicit on constructors in D. But if implicit ends up on copy constructors, at best, it's going to be a language wort, since it adds zero value there, but as the DIP currently stands, it's going to be a source of bugs. - Jonathan M Davis
Sep 24
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
After discussing with Walter and Andrei we have decided that we 
are going to drop  implicit for now as it may cause bugs (as 
Jonathan has highlighted) and consider constructors that have the 
form this(ref $q1 S rhs) $q2 as copy constructors. I will update 
the DIP with more information.

Also, regarding the cohabitation between postblit and copy 
constructor: in order to make the transition smoother, whenever a 
postblit and a copy constructor are found togheter in a struct, 
the former is used and the latter is ignored (even if it is a 
field postblit). Once the postblit is going to be deprecated we 
can do the opposite and use the copy constructor and ignore the 
postblit.

If  implicit is going to be introduced then that is going to be a 
DIP on its own.
Sep 25
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 25, 2018 6:33:30 AM MDT RazvanN via Digitalmars-d-
announce wrote:
 After discussing with Walter and Andrei we have decided that we
 are going to drop  implicit for now as it may cause bugs (as
 Jonathan has highlighted) and consider constructors that have the
 form this(ref $q1 S rhs) $q2 as copy constructors. I will update
 the DIP with more information.

 Also, regarding the cohabitation between postblit and copy
 constructor: in order to make the transition smoother, whenever a
 postblit and a copy constructor are found togheter in a struct,
 the former is used and the latter is ignored (even if it is a
 field postblit). Once the postblit is going to be deprecated we
 can do the opposite and use the copy constructor and ignore the
 postblit.

 If  implicit is going to be introduced then that is going to be a
 DIP on its own.
Yay! Thank you. - Jonathan M Davis
Sep 25
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 25 September 2018 at 12:33:30 UTC, RazvanN wrote:
 After discussing with Walter and Andrei we have decided that we 
 are going to drop  implicit for now as it may cause bugs (as 
 Jonathan has highlighted) and consider constructors that have 
 the form this(ref $q1 S rhs) $q2 as copy constructors. I will 
 update the DIP with more information.

 Also, regarding the cohabitation between postblit and copy 
 constructor: in order to make the transition smoother, whenever 
 a postblit and a copy constructor are found togheter in a 
 struct, the former is used and the latter is ignored (even if 
 it is a field postblit). Once the postblit is going to be 
 deprecated we can do the opposite and use the copy constructor 
 and ignore the postblit.

 If  implicit is going to be introduced then that is going to be 
 a DIP on its own.
Thanks! I still think a -dip10xx flag to control which to prefer is worth doing, since a) it won't be hard to do and will make the transition smoother still , and b) IIRC the motivating factor for this is memory safety. Delaying memory safety while waiting for a deprecation period to expire ( O(years) ) for code that wants to remain backwards compatible with older compiler versions is not something we should be encouraging. In the deprecation period if no flag is given prefer postblit to copy if both are defined, if flag is given prefer copy over postblit. Nic
Sep 25
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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/
Oct 02
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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
Oct 08
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Oct 08
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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.
Oct 08
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 8 October 2018 at 10:27:47 UTC, RazvanN wrote:
 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.
Please elaborate on the reasoning.
 Immediately after the DIP is accepted, the postblit will be 
 deprecated.
Its not about the deprecation process, its about the transitional process, i.e what to do when there is both a postblit and a copy constructor are defined. Whatever the default is, if there is no way to control it, it is impossible to transition smoothly.
Oct 08
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Oct 11