On Tuesday, 26 February 2019 at 22:56:40 UTC, Joseph Rushton Wakeling wrote:
> On Tuesday, 26 February 2019 at 17:46:32 UTC, Jonathan Marler wrote:
>> I think most points of the DIP process make sense, but it has one very large problem.  Feedback from language maintainers (Walter and Andrei) is not done until the end of the process. You're asking someone to go through a process that can take a year before the people who have the power to accept or reject the proposal look at it or leave any feedback.  This is extremely wasteful of the author's time, the reviewer's time and causes extreme pressure for everyone involved.  A years worth of waiting, debate and revision that are now wasted and could have easily been avoided if language maintainers left their feedback early on.  Walter and Andrei should be involved in the process throughout, not just render judgement at the end.
>
> It's worth making a comparison to how new features are incorporated into other languages, such as C++, or Rust, or Fortran, or Haskell.  In every case, it's hard -- years of work trying out different designs, different implementation attempts, balancing costs against benefits.  D is if anything far more flexible than many of its counterparts when it comes to accepting new ideas.
>
> Obviously it's not great if something goes through multiple rounds of feedback and revision only to be rejected at the very end, but sometimes it's only _because_ of those multiple rounds of feedback and revision that a proposal is clear enough to take that kind of decision on it.  Early feedback doesn't help with that.

You said "but sometimes it's only _because_ of those multiple rounds of feedback and revision that a proposal is clear enough".  Which DIPs are you referring to?  I can't identify any proposal that falls into this case.

>
> On the other hand, one can flip the problem on its head: perhaps the problem is less that Walter and Andrei can come in at the end with a rejection, than that things they are going to reject get put in front of them in the first place.  That suggests that either the review process may be ineffective at weeding out problematic proposals, or that DIP authors may be too strongly biased towards revising and resubmitting their proposals rather than withdrawing them when problems are identified.

I agree with what you're saying here but doesn't really speak to the point which is that the process would be much better if Walter and Andrei were involved earlier in the process.  The system as it exists today is almost comically flawed, take a whole year and a lot of people's time to put together a proposal for 2 people without any feedback from them until the end.  Feedback is the most important part of any successful system, without it, the system can quickly diverge and go off on an path, and the longer it goes without feedback to correct itself, the worse and worse it gets.  A year is too long to go without any feedback or course correction.

>
>> In the years I've been here I have found that feedback from anyone other than Walter and Andrei has very little bearing on what Walter and Andrei will think.  The entire community can think an idea is great, but then Walter or Andrei completely reject it.  And the opposite is true as well, I've seen W&A champion an idea that the community generally rejects. Designing a process to ask many people to create and perfect a proposal for a year catered to 2 specific people without any feedback from them is mind-boggling to me.
>
> I'm going to say something comically rude here, but with the serious intent of provoking everyone to reflect a bit.
>
> Which is: have you considered the possibility that Walter and Andrei are the only people who really know what they're talking about, and everyone else is a [expletive] idiot? :-)

Depends on the subject.  There have been times when I've had to explain something to Walter and/or Andrei, they don't know everything.  Languages are very hard to get right and even the smartest people in the world can have completely opposite opinions on things.  I have my own opinion on their strengths and weaknesses, but I think everyone will agree with me that they do have blindspots and weakness, including them.  Well, I suppose you may not agree with me based on what you said :) In general it's not good to base the merit of an idea on who is giving it, humans are very flawed creatures when it comes to completely objective logical discourse no matter how smart someone is.  Instead, merit should be based on the content of an idea, not who gives it.

On Wednesday, 27 February 2019 at 00:06:14 UTC, Joseph Rushton Wakeling wrote:
> On Tuesday, 26 February 2019 at 23:50:12 UTC, Manu wrote:
>> Anyway, follow-on conversation did eventually reveal action points, but by that point, the process has already self-defeated and I'm grumpy and disengaged at this point. The process was the problem here for me, not the verdict.
>
> Adding a fast-track revise-and-appeal seems a straightforward process revision.  If that were to be given a trial in this case as a goodwill gesture, do you think it might have a chance of de-grumpifying you?  (Obviously it's not in my hands to offer that, but raising the idea seems useful.)
>
> If I understand right Nicholas Wilson has proposed a process to deal with this at DConf, so no worries if you would rather follow that route.

;)

> revise-and-appeal

That seems to have already been the case with DIP1009 (expressions based contracts) or at least something like it.

On Wednesday, 27 February 2019 at 00:44:26 UTC, Jonathan Marler wrote:
> You said "but sometimes it's only _because_ of those multiple rounds of feedback and revision that a proposal is clear enough".
>  Which DIPs are you referring to?  I can't identify any proposal that falls into this case.

FWIW Walter has said that if alias this had been proposed today that it would be rejected because it has too many nasty corner cases. I happen to believe alias this is awesome but I do see where he's coming from and I've been reviewing a lot of Razvan's PRs fixing those corner cases so I know they do exist. One of the points on the agenda for the DLF meeting at dconf is a review of the state of alias this.

On Wednesday, 27 February 2019 at 00:15:02 UTC, Manu wrote:
> ...
> Consider DIP 1080:
>
> W&A: this needs work, fix this
> W&A: this needs work, fix this
> W&A: this needs work, fix this
> W&A: this is great, it's pre-accepted
>
> And DIP 1016:
>
> Others: this needs work, fix this
> Others: this needs work, fix this
> Others: this seems fine
> W&A: I'm confused by this word, eject the whole thing into space,
> start again, you're an idiot, this is final, come back 1 year!
>
> Like, this meant to be funny, but it's actually accurate.

Well this is a bit tricky. Because the way you showed above, you fixed what others pointed but not what W&A pointed.

I'm not here to take any sides, but yes in DIP 1080 Andrei/Walter were more active there, and maybe that's is the trickiest part.

In your case just after you presented DIP 1016 that Walter/Andrei appeared.

Finally I know you are an old member and trying to help, so please don't take this DIP rejection personally, I still think you should try one more time, with what W&A pointed and even highlight it in the document and re-applied again.

Donald.

On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via Digitalmars-d wrote:
> On Wednesday, 27 February 2019 at 00:44:26 UTC, Jonathan Marler
>
> wrote:
> > You said "but sometimes it's only _because_ of those multiple rounds of feedback and revision that a proposal is clear enough".
> >
> >  Which DIPs are you referring to?  I can't identify any
> >
> > proposal that falls into this case.
>
> FWIW Walter has said that if alias this had been proposed today that it would be rejected because it has too many nasty corner cases. I happen to believe alias this is awesome but I do see where he's coming from and I've been reviewing a lot of Razvan's PRs fixing those corner cases so I know they do exist. One of the points on the agenda for the DLF meeting at dconf is a review of the state of alias this.

It's one of those features that's occasionally useful, but in general, I'm inclined to think that it causes way more trouble than it's worth. Honestly, implicit conversions in general tend to be problematic much as they can be really nice to have sometimes. They're particularly bad when templates get involved.

- Jonathan M Davis

On Tue, Feb 26, 2019 at 5:05 PM Donald via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 27 February 2019 at 00:15:02 UTC, Manu wrote:
> > ...
> > Consider DIP 1080:
> >
> > W&A: this needs work, fix this
> > W&A: this needs work, fix this
> > W&A: this needs work, fix this
> > W&A: this is great, it's pre-accepted
> >
> > And DIP 1016:
> >
> > Others: this needs work, fix this
> > Others: this needs work, fix this
> > Others: this seems fine
> > W&A: I'm confused by this word, eject the whole thing into
> > space,
> > start again, you're an idiot, this is final, come back 1 year!
> >
> > Like, this meant to be funny, but it's actually accurate.
>
> Well this is a bit tricky. Because the way you showed above, you fixed what others pointed but not what W&A pointed.

Okay, I've repeated this a bunch now, but I'll do it again.
 1. They pointed out the exception problem, which I patched within an
hour or 2 (and was later reverted because 'final'). 'fixing what they
pointed out' is explicitly not welcome according to the process.
 2. Everything else in that text is wrong. I can't address criticism
that's not actually true.

> In your case just after you presented DIP 1016 that Walter/Andrei appeared.
>
> Finally I know you are an old member and trying to help, so please don't take this DIP rejection personally, I still think you should try one more time, with what W&A pointed and even highlight it in the document and re-applied again.

There's nothing in the rejection text other than the exception issue,
which I patched within hours (it was reverted).
The rest of it is completely wrong.

One of the cores of my struggle here beyond getting a re-assessment
with a word changed, was also getting the rejection text revised to be
*true*.
I would appreciate it be on record the reasons that the DIP was
rejected, and not the fantasy that caused it to be rejected. Then
there's clear and visible detail of the path forwards which everyone
can see.
Right now, anybody who goes to that document can read the rejection
text, and they'll assume that it's not just all made up, and that it
somehow represents technical reasons it was rejected.
I appealed for this outcome many times, and it's overtly and
repeatedly denied. Review is 'final', and the rejection text "is what
it is, and we don't owe anybody anything else" (like being correct).

On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via Digitalmars-d wrote:
[...]
> > FWIW Walter has said that if alias this had been proposed today that it would be rejected because it has too many nasty corner cases. I happen to believe alias this is awesome but I do see where he's coming from and I've been reviewing a lot of Razvan's PRs fixing those corner cases so I know they do exist. One of the points on the agenda for the DLF meeting at dconf is a review of the state of alias this.
> 
> It's one of those features that's occasionally useful, but in general, I'm inclined to think that it causes way more trouble than it's worth. Honestly, implicit conversions in general tend to be problematic much as they can be really nice to have sometimes. They're particularly bad when templates get involved.
[...]

I'm a pretty heavy user of alias this, and would be quite unhappy if the present semantics were to change or become deprecated or otherwise cease being supported.  I understand there are some dark corner cases where it's not at all obvious what the "correct" behaviour is, but still, alias this does offer significant value for arithmetical types and wrapper types.  I'd even say that in many cases, it *helps* with templates because it lets you make your custom type work with a template that doesn't (and shouldn't) know about the specifics of your type.

Where it breaks down is when templates are written with assumptions that don't come directly from introspection.  Then you start getting into ambiguous corner cases and other nasty unexpected behaviours.

Anyway, if anything were to change with alias this, we'd better have a darned good replacement for it, because I'll be expecting it!


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

On Tue, Feb 26, 2019 at 5:34 PM H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> > On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via Digitalmars-d wrote:
> [...]
> > > FWIW Walter has said that if alias this had been proposed today that it would be rejected because it has too many nasty corner cases. I happen to believe alias this is awesome but I do see where he's coming from and I've been reviewing a lot of Razvan's PRs fixing those corner cases so I know they do exist. One of the points on the agenda for the DLF meeting at dconf is a review of the state of alias this.
> >
> > It's one of those features that's occasionally useful, but in general, I'm inclined to think that it causes way more trouble than it's worth. Honestly, implicit conversions in general tend to be problematic much as they can be really nice to have sometimes. They're particularly bad when templates get involved.
> [...]
>
> I'm a pretty heavy user of alias this, and would be quite unhappy if the present semantics were to change or become deprecated or otherwise cease being supported.  I understand there are some dark corner cases where it's not at all obvious what the "correct" behaviour is, but still, alias this does offer significant value for arithmetical types and wrapper types.  I'd even say that in many cases, it *helps* with templates because it lets you make your custom type work with a template that doesn't (and shouldn't) know about the specifics of your type.
>
> Where it breaks down is when templates are written with assumptions that don't come directly from introspection.  Then you start getting into ambiguous corner cases and other nasty unexpected behaviours.
>
> Anyway, if anything were to change with alias this, we'd better have a darned good replacement for it, because I'll be expecting it!

I use `alias this` a lot, but that's just because it's the only tool we have.
`@implicit` constructors (and/or cast operators) would resolve all
uses I can think of, and I think the rules on those would be much
simpler.

On Tuesday, February 26, 2019 6:34:04 PM MST H. S. Teoh via Digitalmars-d wrote:
> On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via
Digitalmars-d wrote:
> > On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via
>
> > Digitalmars-d wrote:
> [...]
>
> > > FWIW Walter has said that if alias this had been proposed today that it would be rejected because it has too many nasty corner cases. I happen to believe alias this is awesome but I do see where he's coming from and I've been reviewing a lot of Razvan's PRs fixing those corner cases so I know they do exist. One of the points on the agenda for the DLF meeting at dconf is a review of the state of alias this.
> >
> > It's one of those features that's occasionally useful, but in general, I'm inclined to think that it causes way more trouble than it's worth. Honestly, implicit conversions in general tend to be problematic much as they can be really nice to have sometimes. They're particularly bad when templates get involved.
>
> [...]
>
> I'm a pretty heavy user of alias this, and would be quite unhappy if the present semantics were to change or become deprecated or otherwise cease being supported.  I understand there are some dark corner cases where it's not at all obvious what the "correct" behaviour is, but still, alias this does offer significant value for arithmetical types and wrapper types.  I'd even say that in many cases, it *helps* with templates because it lets you make your custom type work with a template that doesn't (and shouldn't) know about the specifics of your type.
>
> Where it breaks down is when templates are written with assumptions that don't come directly from introspection.  Then you start getting into ambiguous corner cases and other nasty unexpected behaviours.

Basically, if your template constraint tests for an implicit conversion, it then needs to force that implicit conversion rather than assuming that the type provided acts like the target type. If you don't force the conversion, then some operations may act like the target type and some may not (it may even do the conversion with some operations and use the actual type in others), and you could get some pretty weird bugs. It can work work if you force the implicit conversion, but really, if you're dealing with implicit conversions and templated code, you have to be careful, and in general, it's far less error-prone to just not use implicit conversions with templated code and require that the caller do the conversion.

> Anyway, if anything were to change with alias this, we'd better have a darned good replacement for it, because I'll be expecting it!

I'd be very surprised if alias this got axed at this point.

- Jonathan M Davis

On 2/26/19 5:09 PM, Andrei Alexandrescu wrote:
> On 2/26/19 3:09 PM, James Blachly wrote:
>> On Tuesday, 26 February 2019 at 19:49:52 UTC, Andrei Alexandrescu wrote:
>>> Yah, I know of the process from my wife. There are quite a few differences between the fields. One is that in medicine a case presentation is in and by itself publishable material, and all the editor needs to do is assess the rarity and relevance of the material.
>>
>> I am not at all describing “case reports,” and your thoughtless dismissal of earnest feedback/suggestion really underlines the criticisms others have leveled against you specifically, and perhaps the process generally.
> 
> Didn't that escalate a bit quick? You wrote the goings in your field with no further argument as to how the process would be translated to our case. I shared the little insight I had, too, in expectation of more detail. How is one a earnest feedback/suggestion and the other thoughtless dismissal?

I acknowledge and apologize. I misinterpreted your terseness as tacit dismissal based on a preformed negative impression without getting to know you personally. Mea culpa.

To return to the analogy, from the perspective of an outsider [to the DIP process], the scientific article (I am speaking here of hypothesis-driven research) submission/peer referee process and the DIP submission/revision process appear quite similar, as you pointed out.

To clarify further, rejection after review and possibly multiple rounds of revision is a disappointing, but expected outcome. In this sense it is like the DIP process and I believe even Manu has said that this is an acceptable outcome, so long as the review was fair.

Upthread, J. Marler made the suggestion that a suitable authority or designee may be able to provide a "pre-review". This is indeed common in biomedicine: a journal's associate editor may provide an estimate of suitability of the study in question, before the manuscript is formatted to the journal's specific requirements or before final supplementary experiments and figures are compiled. If one is lucky, some general guidance about suggested experiments that might be necessary prior to acceptance may be given. If I know that _Nature Genetics_ is not at all interested in my manuscript (due to editorial priorities, or study scope, or whatever) I can save a lot of time. In the sense that I have multiple options (perhaps formatting and targeting instead _Genome Biology_) this is dissimilar to DIP.

Even more importantly, **after each round of revisions in the scientific paper submission process, the editor or associate editor provides commentary regarding the reviews as received (and as a scientist themself is responsible for recognizing inappropriate, inaccurate, or unfair peer review) and makes a judgement about whether to accept the manuscript, proceed pending  additional minor or major revisions, or reject.** This I find key, and could make the most improvement in the DIP review process.

Ultimately, I agree with other commenters that it could be helpful to have feedback from the language maintainers much earlier in the process than at the very end of a potentially long road. Clearly no one can compel Andrei and Walter to provide more of their limited time, but some additional intervention, whether in pre-review, or shepherding of reviews, may go along way toward alleviating the concerns raised recently.

Offered in a spirit of helpfulness,
James Blachly