On 10/17/2016 01:44 PM, David Soria Parra wrote:
> Looking at other languages that have similar process. Python's PIPs are
> probably the closest to DIP. Two observations:
>
> 1. Python as clean tooling around PIPs. We should render PIPs from the
> dlang/DIP nicely at dip.dlang.org (My understanding that repository is
> now favored over wiki entries).
>
> 2. Python DIPs are Guido's main focus of work. Maybe we can write a bot
> mailing current in-process DIPs on a weekly basis to the mailinglist as
> digest to remind Walter, Andrei and others to reviewed. The list should
> ordered by last comment/review on it. I am not 100% aware of all the
> edge cases of the process and have a terrible track record of
> implementing things I say i will implement, but I can give such a
> mailing bot a try, by scaping dlang/DIP.
>
> 3. It would be great to be clear if the people who can accept a DIP
> reviewed it and what the current suggested improvements are so we can
> make constant head-way.

Thanks, David. Hope you're doing well! I was curious about one thing - is there some scrutiny going into the PIPs before Guido reviews them? Right now we seem to have a scalability issue; some of the DIPs we have seem to be no more than a couple of hours of work from the submitters. Writing a good review for a submission that needs a lot of improvement is in many ways more difficult than reviewing a well-argued DIP.

I was therefore wondering - given Python's popularity - whether there is some filtering of PIPs prior to them being reviewed by Guido.


Thanks,

Andrei

On Monday, 17 October 2016 at 21:52:32 UTC, Andrei Alexandrescu wrote:
> Thanks, David. Hope you're doing well! I was curious about one thing - is there some scrutiny going into the PIPs before Guido reviews them? Right now we seem to have a scalability issue; some of the DIPs we have seem to be no more than a couple of hours of work from the submitters. Writing a good review for a submission that needs a lot of improvement is in many ways more difficult than reviewing a well-argued DIP.
>
> I was therefore wondering - given Python's popularity - whether there is some filtering of PIPs prior to them being reviewed by Guido.

PEPs (sorry I totally misspelled that before) have a editors who are responsible for scrutinizing the PEP before and as far as I understand are the ones who can request review from the BDFL (Guido), who either takes the final decision or delegates it (e.g. in cases were someone is better suited in the area to make the call). Editors are trusted core committers that are sponsoring an improvement.

The process is outline in great detail at https://www.python.org/dev/peps/pep-0001/#pep-workflow and I recommend reading it. Maybe we get some good ideas on how to create a process that is scalable and results in the high quality standards we have but are more suited towards the smaller community we are.

We should start small and see how we find something that Walter, you and contributors feel good about and improve from there:

might suit our needs.

On 17 October 2016 at 15:02, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 10/16/2016 3:17 PM, deadalnix wrote:
>>
>> Long story short, it si clearly a waste of time. Qualifying the process
>> would be
>> an understatement.
>>
>> Some specifically DIP27 has been written in Feb 2913, following various
>> discussion at that time. I pushed it at the time. I moved it to the new
>> git DIP
>> repository. Got mostly irrelevant feedback (Hi Martin) and more generaly
>> the
>> loop time is measured in month.
>
>
> The wiki DIP27 is here:
>
>   https://wiki.dlang.org/DIP27
>
> listed as a draft, last change Sep 2014. I don't see it in the new DIP repository:
>
>   https://github.com/dlang/DIPs
>
> either submitted, approved, or in a PR.
>
>
>> I'm doing this on my free time. I have other things to do.
>>
>> The DIP process is beyond broken. It essentially goes as :
>>  - If you are Andrei or Walter, then your DIP is just a formality. No
>> matter how
>> bad it is, it is in (Hi DIP25, inout turned out so great for type
>> qualifier we
>> clearly need that for lifetime).
>>  - If anybody else does it, you have no idea what you are getting into.
>> You'll
>> be still there in 5 years with no end in sight.
>
>
> Here's the list of approved DIPs. (It's a short list.)
>
>   https://github.com/dlang/DIPs/blob/master/DIPs/archive/README.md
>
>
>> I've been a sucker for long enough. I'm not playing anymore and I'd
>> suggest to
>> anyone playing to stop. I've probably be playing longer than pretty much
>> anyone
>> here. Trust the bitter old man, he knows.
>
>
> I know it's hard to get any language changes approved. Arguably, it should be hard. For better or worse, it also takes those who believe in it to promote it, convince others of its value, and get behind it an push, hard.

You mean like that time I spent at least 2 years fighting for
final-by-default, won over the entire community except for a single
person who said they were indifferent (who I forget who was).
Even you begrudgingly conceded (or at least appeared to), the change
was implemented, reviewed, merged, and then Andrei appeared back from
holiday or wherever, and got angry that it happened in his absence and
said he would *never* approve such a thing, and immediately reverted
the patch...?

One of the most democratic experiences of my life ;)

I would be involved in the 'scope' DIP, but I fear my contribution
would work against my interests. I'm currently unhappy with it, but I
don't really care anymore. I've lost sight of the dream ;)
I just want to be able to pass an rvalue to a function that receives a
const ref... that's why I came to this forum in the first place like,
7 years ago. 7 years later... still can't.

On 10/17/2016 7:54 PM, Manu via Digitalmars-d wrote:
> You mean like that time I spent at least 2 years fighting for
> final-by-default, won over the entire community except for a single
> person who said they were indifferent (who I forget who was).
> Even you begrudgingly conceded (or at least appeared to), the change
> was implemented, reviewed, merged, and then Andrei appeared back from
> holiday or wherever, and got angry that it happened in his absence and
> said he would *never* approve such a thing, and immediately reverted
> the patch...?
>
> One of the most democratic experiences of my life ;)
>
> I would be involved in the 'scope' DIP, but I fear my contribution
> would work against my interests. I'm currently unhappy with it, but I
> don't really care anymore. I've lost sight of the dream ;)
> I just want to be able to pass an rvalue to a function that receives a
> const ref... that's why I came to this forum in the first place like,
> 7 years ago. 7 years later... still can't.
>

You've gotten user defined attributes in the language (and very undemocratically, I might add!), Win64 support, VC++ symbolic debug info, a number of improvements to C++ class support, SIMD support, SIMD intrinsics, pragma inline, yeah, we never listen to you :-)

You've been a large influence over D, and a very positive one.

On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:
> I just want to be able to pass an rvalue to a function that receives a
> const ref... that's why I came to this forum in the first place like,
> 7 years ago. 7 years later... still can't.

I recently wrote a PR for p0nce D idioms, which shows how you can do that
https://github.com/p0nce/d-idioms/pull/119

On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:
> On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:
>> I just want to be able to pass an rvalue to a function that receives a
>> const ref... that's why I came to this forum in the first place like,
>> 7 years ago. 7 years later... still can't.
>
> I recently wrote a PR for p0nce D idioms, which shows how you can do that
> https://github.com/p0nce/d-idioms/pull/119

there is a huge difference between "i can hack around it" and "i can do it".

On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:
> On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:
>> On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:
>>> I just want to be able to pass an rvalue to a function that receives a
>>> const ref... that's why I came to this forum in the first place like,
>>> 7 years ago. 7 years later... still can't.
>>
>> I recently wrote a PR for p0nce D idioms, which shows how you can do that
>> https://github.com/p0nce/d-idioms/pull/119
>
> there is a huge difference between "i can hack around it" and "i can do it".

True. ;) It's like the static-array-without-length-and-gc hack. You can do it with language constructs but it's inconvenient. So it's up to Walter and Andrei to decide if this inconvenience is bearable or not.

On Tuesday, October 18, 2016 13:36:42 Namespace via Digitalmars-d wrote:
> On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:
> > On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:
> >> On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:
> >>> I just want to be able to pass an rvalue to a function that
> >>> receives a
> >>> const ref... that's why I came to this forum in the first
> >>> place like,
> >>> 7 years ago. 7 years later... still can't.
> >>
> >> I recently wrote a PR for p0nce D idioms, which shows how you
> >> can do that
> >> https://github.com/p0nce/d-idioms/pull/119
> >
> > there is a huge difference between "i can hack around it" and "i can do it".
>
> True. ;) It's like the static-array-without-length-and-gc hack. You can do it with language constructs but it's inconvenient. So it's up to Walter and Andrei to decide if this inconvenience is bearable or not.

Andrei decided ages ago that he didn't think that having const ref take rvalues was a good idea and that he doesn't think that it's a big deal. I don't recall whether Walter has said much on the issue, but AFAIK, he hasn't said anything to contradict that, and Andrei has been very vocal about how rvalue references were a horrible mistake in C++ and that he doesn't want to see anything of the sort in D. auto ref parameters solve the problem on some level, and it seems that that's the closest you're going to get to getting rvalue references in the language. I think that it's pretty clear at this point that it's not very likely that anyone is going to change Andrei's mind on this one.

- Jonathan M Davis

On 10/18/2016 01:51 PM, Jonathan M Davis via Digitalmars-d wrote:
> Andrei has been very vocal about how
> rvalue references were a horrible mistake in C++

Please misquote appropriately :o). I said binding rvalues to const ref is the mistake that led to the rvalue references complication. That's the truth and nothing but the truth, but not the whole truth; one thing is that the rvalue references features covers additional things not caused by the const ref mistake. -- Andrei

On 10/18/2016 07:51 PM, Jonathan M Davis via Digitalmars-d wrote:
> Andrei decided ages ago that he didn't think that having const ref take
> rvalues was a good idea and that he doesn't think that it's a big deal. I
> don't recall whether Walter has said much on the issue, but AFAIK, he hasn't
> said anything to contradict that, and Andrei has been very vocal about how
> rvalue references were a horrible mistake in C++ and that he doesn't want to
> see anything of the sort in D.

It would be great if we had detailed rationale articles for these non-obvious decisions.

First, so that people get a nice prepared answer for why D is different. I can't confidently spell out why D doesn't allow passing an rvalues in a const ref parameter, and I suspect that only Andrei really can.

Second, so that the decision can be attacked argumentatively. Walter and Andrei have been mistaken before, just like everyone else. It wouldn't surprise me if some variation of the feature was feasible, but it's hard to even think in that direction when the reasons against it are buried and scattered around in newsgroup discussions.