Or rather more importantly why haven't this pull request been reviewed yet?
https://github.com/dlang/dlang.org/pull/2453

It been documented already, just review it and merge it. I literately can't find the words to describe the unnecessarily stubbornness being displayed without came across as unprofessional.

The work has been done! Just review it and merge it! I don't what to do, other then to beg here.

-Alex

On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:
> Or rather more importantly why haven't this pull request been reviewed yet?
> https://github.com/dlang/dlang.org/pull/2453
>
> It been documented already, just review it and merge it. I literately can't find the words to describe the unnecessarily stubbornness being displayed

Join the club!

> without came across as unprofessional.

Been there, done that.

> The work has been done! Just review it and merge it!

IKR, unfortunately only Walter or Andrei can do that because only they understand DIP1000, and unfortunately Walter has ignored almost all attempts to communicate this, except once recently to the tune of "thanks for doing something about this rather than complaining about it, but no thanks because [insert some bureaucratic reason]" which raised the ire of quite a number of people.

> I don't what to do, other then to beg here.

Done that too.

On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:
> Or rather more importantly why haven't this pull request been reviewed yet?
> https://github.com/dlang/dlang.org/pull/2453

I really want to know too! He's been pushing for DIP1000 so hard, yet doesn't leave even a single post to co-operate when people are helping.

It might be that he doesn't have time for reviewing, or that DIP1000 is still moving too fast to properly document, but that's hard to imagine since he has already prepared and given two presentations at DConf about the very topic.

Walter, whatever the reason for this is, at least you need to say it! Otherwise, people don't know what to do, and demoralize a LOT.

On Tuesday, 20 November 2018 at 15:40:00 UTC, Dukc wrote:
> but that's hard to imagine since he has already prepared and given two presentations at DConf about the very topic.

Remembered wrong. One. But the point stands.

On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:
> Just review it and merge it! I don't what to do, other then to beg here.

I completely agree.

On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:
> Or rather more importantly why haven't this pull request been reviewed yet?
> https://github.com/dlang/dlang.org/pull/2453
>
> It been documented already, just review it and merge it. I literately can't find the words to describe the unnecessarily stubbornness being displayed without came across as unprofessional.
>
> The work has been done! Just review it and merge it! I don't what to do, other then to beg here.
>
> -Alex

Please. It feels like it has been forever since it was first proposed.

On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:
> The work has been done! Just review it and merge it! I don't what to do, other then to beg here.

People are different and have different goals of their development with D. In my experience, the only productive way forward is to encourage, reward and help out. And that not only with the things you are interested in. Walter has recently been swamped and very productive with porting the backend to DMD which is a great step forward that's gonna reduce many bugs in the long run. Walter likes bugzilla. If you add things there and send him the ref he will sooner or later do something about it. He has fixed bugs regarding dip1000 I have filed there. If you start asking people what they need help with, the chance of DIP-1000 getting in is gonna increase.

Ask not what D can do for you, but
What You can do for D.

/Per

On Thursday, 22 November 2018 at 08:44:10 UTC, Per Nordlöw wrote:
> On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:
>> The work has been done! Just review it and merge it! I don't what to do, other then to beg here.
>
> People are different and have different goals of their development with D. In my experience, the only productive way forward is to encourage, reward and help out. And that not only with the things you are interested in. Walter has recently been swamped and very productive with porting the backend to DMD which is a great step forward that's gonna reduce many bugs in the long run. Walter likes bugzilla. If you add things there and send him the ref he will sooner or later do something about it. He has fixed bugs regarding dip1000 I have filed there. If you start asking people what they need help with, the chance of DIP-1000 getting in is gonna increase.
>
> Ask not what D can do for you, but
> What You can do for D.
>
> /Per

I believe the real issue is that...
https://github.com/dlang/dmd/pull/8504
... has not been merged.

If Walters fix is approved the spec can be merged directly afterwards.

The first parameter, like it or not, has special status in many situations, ex:
* implicit this
* properties
* chaining UFCS

Now Walter wants to add a 4th item to this list, someone either needs to approve it or come up with a better idea, otherwise we won't get anywhere, I for one would happily approve it but I obviously don't have the authority to do so.

If an entirely different solution is chosen, then this spec pull would document something which never even existed, that's why it's key to pull 8504 first imho, as then the semantics is cemented.

On Thursday, 22 November 2018 at 09:05:59 UTC, Daniel N wrote:
> I believe the real issue is that...
> https://github.com/dlang/dmd/pull/8504
> ... has not been merged.
>
> If Walters fix is approved the spec can be merged directly afterwards.
>
> The first parameter, like it or not, has special status in many situations, ex:
> * implicit this
> * properties
> * chaining UFCS
>
> Now Walter wants to add a 4th item to this list, someone either needs to approve it or come up with a better idea, otherwise we won't get anywhere, I for one would happily approve it but I obviously don't have the authority to do so.
>
> If an entirely different solution is chosen, then this spec pull would document something which never even existed, that's why it's key to pull 8504 first imho, as then the semantics is cemented.

dlang.org#2453 is a blocker for that, and _not_ the other way round, for the sole reason that without knowing what it is supposed to do, it is impossible to review (the bugzilla issues are not helpful).

Note that dlang.org#2453 also documents other changes to dip1000 that walter has made and has chosen not to document (just recently I had to inform Razvan who is otherwise a very capable compiler developer what the situation was because there is no documentation), which makes the whole process even worse because the implementation bears less and less resemblance to the documentation and keeping track of interactions gets combinatorially more difficult, and when reviewers are faced with that they simply just do not review.

On Thursday, 22 November 2018 at 10:12:12 UTC, Nicholas Wilson wrote:
>
> dlang.org#2453 is a blocker for that, and _not_ the other way round, for the sole reason that without knowing what it is supposed to do, it is impossible to review (the bugzilla issues are not helpful).
>
> Note that dlang.org#2453 also documents other changes to dip1000 that walter has made and has chosen not to document (just recently I had to inform Razvan who is otherwise a very capable compiler developer what the situation was because there is no documentation), which makes the whole process even worse because the implementation bears less and less resemblance to the documentation and keeping track of interactions gets combinatorially more difficult, and when reviewers are faced with that they simply just do not review.

"impossible to review" is a very strong statement, how then were you able to write the spec? I had no issues understanding what Walter meant both comments and the test cases speak for themselves, he also offered to answer any questions.

If there is any corner case which you don't understand, it would imho be more constructive to ask him to add a new test case for it in #8504 so that any ambiguity will be cleared, future regressions prevented and coverage improved. It's very easy to misunderstand a written explanation, but code can only be interpreted one way. This is even more so for an international project where not everyone is a native English speaker.

In my world the spec/doc/changelog is just a release blocker for the next official external compiler release, but by all means merge them simultaneously, now that they both are available.