Copy Constructor DIP

[Manu]

On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 07/12/2018 11:14 AM, Luís Marques wrote:
> > On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
> >> When designing D libraries than lean towards DSL style, I've
> >> frequently felt impaired by the lack of implicit conversions in D. In
> >> my experience, it's not that all types need to be implicitly
> >> convertible to other types. Just being able to mark a few types as
> >> implicitly convertible to some other specific types would go a long
> >> way to alleviate the limitations I felt. It would also solve problems
> >> like an arbitrary limit on the depth of implicit conversions.
> >>
> >> I had imagined that maybe one day an implicit keyword could be
> >> introduced to mark such permissible implicit conversions. Seeing an
> >> implicit "keyword" being introduced here with different semantics than
> >> I envisioned makes me even less hopeful that some day such implicit
> >> conversions annotations could be introduced. So... maybe consider
> >> choosing some other syntactic notation? Besides, the fact that the
> >> compiler can implicitly introduce calls to the copy ctor doesn't
> >> strike me as something particularly central to the concept, so it
> >> seems like an odd choice for something to distinguish a copy ctor.
> >
> > 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.
>
> No, only constructors annotated with @implicit would be implicit. But
> that's only a possible future direction not part of this DIP.
>
> Also there are many complications related to allowing implicit
> conversions across distinct types, and this DIP should not get embroiled
> in those. That would be a different pursuit that I encourage you to
> consider.

I feel like this DIP depends on an @implicit DIP, and that one needs
to come first...