Copy Constructor DIP

[Luís Marques]

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. 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.