On Thu, 12 Jul 2018 at 08:30, Luís Marques via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote: > > More details. The DIP says: > > > > "The structName type needs to be identical to typeof(this); an > > error is issued otherwise. This requirement may be relaxed in > > the future in order to accomodate copying from objects of a > > different type" > > (BTW, typo in "accomodate") > > > > That would mean that if such a relaxation were introduced, then > > suddenly *all* copy ctors would imply implicit conversion > > between the respective types. Given D's stance on implicit > > conversions, I suspect that's not going to pass mustard. So I > > would prefer the any "implicit" keyword-like annotation to be > > reserved for explicitly approved implicit conversions. > > BTW: Multiple alias this is still planned for inclusion in D, > right? If so, what would be the (pratical?) difference between > having copy ctors with such a relaxed type requirement and just > defining an equivalent alias this method? In case the answer is > that there's no significant difference, why not drop multiple > alias this, then?
@implicit constructors state what types an object may *accept*. alias this specifies what types an object may *provide*. They're both about implicit conversion, but specified at either the providing or receiving end. I think they both have reason to exist; they're complementary. It depends if you're authoring an API, or writing a tool to interact with an existing API which is appropriate to use.
