On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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...
