Copy Constructor DIP

[Manu]

On Fri, 13 Jul 2018 at 07:35, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 7/12/18 11:45 PM, Manu wrote:
> >
> > 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".

What "I don't like" is using an attribute as a marker, and especially
in the unique case of a copy constructor, which is so fundamental to
the language.
If it has a systemic meaning, as it's sort-of proposed that maybe it
might in the future sometime, then it's fine.

There's a lot of subjectivity in programming. I don't like that python
has significant white-space. I don't like that Javascript isn't a
native language.
I don't like the idea of introducing an attribute as a marker in a
single case, without some expectation that it has a future beyond
that.

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

As I originally said, my feedback is concrete: specify @implicit, this
DIP depends on it.
My language like "@implicit done right" came later, as a reference to
prior comments.

As I've said, I actually really want @implicit, but I want to be
satisfied by it's definition and somewhat convinced that it has a
future, and specifically, that it's NOT just a marker to be used in
this case.

It's not about 'asking others to put in the work', this DIP has a
dependency on it, so it can't not be defined. The definition is
currently "it's a marker, and maybe we might do something in the
future", and that's a poor definition.
If I presented a DIP which casually dropped in a new attribute, you
would absolutely insist that I specify it.

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

There's also @property... and 'scope' as existed prior DIP1000, and 'in'.
I think this thing needs at least a little spec-ing. If it's clear up
front that it's not going anywhere (easily shot-down or whatever),
then it's not a good choice.
If it looks generally promising for the future, and there's no obvious
roadblocks for wider deployment, then we're good, and I'll desist on
this point.
I don't know how we can be confident of that without at least a little
exploration.

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

Presenting a proposal to the community is an implicit request for
support. I'm not saying I have any power further than my reading of
the proposal and sharing my own judgement of its merit.
You can do whatever you do... I'm just saying what I find satisfying,
and this proposal is not satisfying without some further
substantiation of the proposed new attribute.

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

I've already contributed other points to this DIP in the way you describe.
This one however is very strange, and I'm surprised you can find the
hand-wavy introduction of a new attribute without any sense of where
it's going to be okay. Or maybe, I'm surprised I'm the only one that
finds problem with that.
My feeling is inspired by '@property', 'scope', 'in'. We don't need
any more events like those.