Copy Constructor DIP

[Andrei Alexandrescu]

On 7/12/18 11:45 PM, Manu wrote:
> On Thu, 12 Jul 2018 at 20:15, Meta via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>> 
>> On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote:
>>> 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?
>> 
>> Nothing is being slipped by as far as I'm concerned. @implicit is 
>> solely introduced in the DIP as a marker for the copy constructor,
>> and it doesn't seem like it's intended for anything further than
>> avoiding breaking code. It feels to me like you're making a
>> mountain out of an ant hill.
> 
> That's the whole point though. We're debating whether "@implicit" is
> a good idea. And it's the only detail of the DIP that feels
> noteworthy or contentious to me. The rest is pretty much
> common-sense, and long overdue.
> 
> I can see myself getting behind 2 possibilities, no @implicit, or 
> @implicit done right.

A couple of simple ideas are making the process productive. One is to
rely on facts instead of feelings. "It's weird" or "I don't like it" are
less helpful than "semantics of this or that case are not covered".

Another is precision. Stating vague goals and standards ("I want
@implicit done well") and systematically asking others to actually put
in the work is less desirable than providing concrete, motivated, 
actionable feedback.

To the second point: we have a history of defining features too 
permissively, to then regret not having waited to accumulate experience. 
Starting with a restricted version then building on experience with it 
seems to be a much better strategy. From that perspective, introducing 
implicit only for restricted copy construction seems like a good step 
that doesn't take others, without precluding them.

> I don't see myself getting behind introduction of @implicit on such 
> terms that it's nothing but "a marker for the copy constructor". So 
> this 'mountain' is critical to understanding whether I can support 
> this DIP as proposed or not.

I'd put it a slightly different way. "Getting behind" and "supporting or 
not" suggests a position of power and an emphasis on the politics of the 
process. The natural counter to this would be asking whether your 
support is necessary, which put us all in a very unproductive position.

The right emphasis is not getting your support on a given DIP, but 
instead us all benefiting of your active contribution to a better DIP.


Thanks,

Andrei