Copy Constructor DIP

[Manu]

On Fri, 13 Jul 2018 at 17:45, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 7/13/18 5:28 PM, Manu wrote:
> > As I originally said, my feedback is concrete: specify @implicit, this
> > DIP depends on it.
>
> The specification of @implicit is in the DIP in full: a constructor that
> takes by reference a qualified typeof(this) and has the @implicit
> attribute will be callable implicitly by the compiler. There is no other
> meaning of @implicit. That completes the spec of @implicit.

Right, and this is 100% of my concern here.
To introduce a new attribute for such a one-off purpose feels like a
poor choice, and on those terms I would rather see the feature work
with no such attribute (as we've considered in the other fork). If you
assess the likelihood of actually breaking code in the wild (I expect
it's super slim; data would be nice), you might find that the risk is
satisfactory.

However, the DIP alludes to a possible future for the attribute, and I
think that text is intended to make us feel better about the
introduction of the attribute, but I would be a lot more comfortable
with a more substantial support of its introduction.
Basically, and you already know this; I think it's a weird choice to
introduce a new attribute for this one-off case, but as a systemic
feature which addresses a general long-standing problem, it feels like
a good and logical solution.

I think we need some idea if the broader application is even
theoretically workable up-front. If there's obvious issues with the
idea of deploying @implicit generally, then we shouldn't deploy it
here, and instead, we should deploy something else here which CAN
successfully be generalised in the future.
Determining that requires at least a cursory exploration.