On Fri, 13 Jul 2018 at 07:35, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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.