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.
