Copy Constructor DIP

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Jul 12 15:32:16 UTC 2018


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.


More information about the Digitalmars-d mailing list