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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018
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 2018