On Fri, 13 Jul 2018 at 17:45, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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.