Copy Constructor DIP

[Manu]

On Thu., 12 Jul. 2018, 7:10 pm Andrei Alexandrescu via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

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

Double-negative.. why would we support introduction of this @implicit
attribute if it's not proposed how it will work in general?
Introducing more attributes is a big deal.

For the record, now that I 'get it', I'm super jazzed about having
@implicit in the language. I've wanted it since day-one!
But I don't want to be swindled into accepting its existence prior to being
comfortable that the design/intent/implementation is right. We can't get it
out if the theoretical future DIP that makes it broadly useful is not
agreeable.
The potential introduction of @implicit makes me about 100x more interested
(and critical) of this DIP. Now that it's on the table, I *really* care
that this goes right.

Seriously, if I was making this proposal to you, and you were in my
position... there is no way in hell that you'd allow any of us to slip
something so substantial by like that with the wave of a hand.
This DIP depends on @implicit. How can you argue otherwise?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20180712/188a8457/attachment-0001.html>