Copy Constructor DIP

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jul 13 02:05:38 UTC 2018


On 7/12/18 7:15 PM, Manu wrote:
> On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at 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...

Negative.



More information about the Digitalmars-d mailing list