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?

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

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.

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.

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.

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.

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

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

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:

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.