On Wednesday, 24 October 2018 at 20:51:11 UTC, Walter Bright wrote:
> On 10/23/2018 10:20 PM, Neia Neutuladh wrote:
>> The change seems small to you, so documenting it at the same time as the
>> PR is out doesn't seem that important. But it still needs to be
>> documented, and people are asking for the documentation to help with
>> reviewing the PR. Why not just write the documentation? It's been three
>> months.
>
>
> It is documented here: https://issues.dlang.org/show_bug.cgi?id=19097
>
> If you don't understand it, feel free to ask.

Bugzilla is meant to report bugs, not document features. You risk alienating the rookies here.

-Alex

On Wednesday, 24 October 2018 at 21:01:17 UTC, 12345swordy wrote:
> Bugzilla is meant to report bugs, not document features. You risk alienating the rookies here.
>
> -Alex

As a rookie I agree with Alex. I would not look for documentation in bugzilla. D language is big and compiler internals are complex. I need all documentation I can get

On Wed, 24 Oct 2018 13:51:11 -0700, Walter Bright wrote:
> On 10/23/2018 10:20 PM, Neia Neutuladh wrote:
>> The change seems small to you, so documenting it at the same time as the PR is out doesn't seem that important. But it still needs to be documented, and people are asking for the documentation to help with reviewing the PR. Why not just write the documentation? It's been three months.
> 
> 
> It is documented here: https://issues.dlang.org/show_bug.cgi?id=19097
> 
> If you don't understand it, feel free to ask.

People are asking for a spec update with specification-level clarity and precision. This will be required prior to the next major release after that PR gets submitted. Why not do it now?

On Wednesday, 24 October 2018 at 01:31:33 UTC, Walter Bright wrote:
> On 10/23/2018 4:56 PM, Nicholas Wilson wrote:
>> He doesn't need to, I did it for him: https://github.com/dlang/dmd/pull/8504
>> He just needs to review it.
>
> https://github.com/dlang/dlang.org/pull/2453
>
> While I thank and appreciate you for doing this work, and especially for taking the initiative instead of just complaining, I don't think that modifying a DIP that has already been approved is appropriate process. It should be a PR against the spec. Approved specs should be immutable.

[...]

With all due respect, why wasn't this brought forward as a comment on the PR back in August? (And it _is_ a PR against the spec, is it not?) I feel embarrassed for the image that is being presented outwards, which is one of central people being incapable of working together. I don't understand what is going on; how could the language evolve this far and what has changed? Do we have too much regulation and procedures or too little? Isn't Walter's explanation in bugzilla enough this time to review his PR and keep the language improving while procedures are being improved on in parallel? I feel like people are keeping a stiff foot for far too long. Stagnation in development is bad enough, but this image really hurts me. I count on you, I want you guys to shine. I see all these talented musicians, but the conductor is not on his podium.

Come on, friends, you've cracked harder nuts. Please :-)

Bastiaan.

On Wednesday, 24 October 2018 at 21:01:17 UTC, 12345swordy wrote:
> On Wednesday, 24 October 2018 at 20:51:11 UTC, Walter Bright wrote:
>> On 10/23/2018 10:20 PM, Neia Neutuladh wrote:
>>> The change seems small to you, so documenting it at the same time as the
>>> PR is out doesn't seem that important. But it still needs to be
>>> documented, and people are asking for the documentation to help with
>>> reviewing the PR. Why not just write the documentation? It's been three
>>> months.
>>
>>
>> It is documented here: https://issues.dlang.org/show_bug.cgi?id=19097
>>
>> If you don't understand it, feel free to ask.
>
> Bugzilla is meant to report bugs, not document features.

We have told Walter that so many times before, I've lost count and he still doesn't listen. I don't know why I bother.

> You risk alienating the rookies here.

That statement is wrong for two reasons:
1) there is no risk, it has happened, and
2) it applies to everyone, not just the rookies. Atila, who has done more production use of dip1000 than anyone else I know, was recently (for some value of recently) surprised at the way it worked in some way (that I can't be bothered to cite at the moment, jet lag).

On Thursday, 25 October 2018 at 00:20:17 UTC, Bastiaan Veelo wrote:
> On Wednesday, 24 October 2018 at 01:31:33 UTC, Walter Bright wrote:
>> On 10/23/2018 4:56 PM, Nicholas Wilson wrote:
>>> He doesn't need to, I did it for him: https://github.com/dlang/dmd/pull/8504
>>> He just needs to review it.
>>
>> https://github.com/dlang/dlang.org/pull/2453
>>
>> While I thank and appreciate you for doing this work, and especially for taking the initiative instead of just complaining, I don't think that modifying a DIP that has already been approved is appropriate process. It should be a PR against the spec. Approved specs should be immutable.
>
> [...]
>
> With all due respect,

I'm pretty sure all respect is past its dues on this, but anyway...

> why wasn't this brought forward as a comment on the PR back in August?

I don't know, Walter hasn't bothered to reply.

> (And it _is_ a PR against the spec, is it not?)

Technically yes. But what should we document, the spec or the status quo?

> I feel embarrassed for the image that is being presented outwards, which is one of central people being incapable of working together. I don't understand what is going on; how could the language evolve this far and what has changed? Do we have too much regulation and procedures or too little?

> Isn't Walter's explanation in bugzilla enough this time to review his PR and keep the language improving while procedures are being improved on in parallel?

dlang/dmd#8346 dlang/dmd#8408 were merged on the understanding that the documentations changes would follow (this is indeed sometimes a useful pattern so we went through with it).

For dlang/dmd#8504 without the documentation we simply cannot review it, on principle and in practice. The principle sets a bad example which I can only guess that Walter will keep doing. The practical is that if we do not understand the PR there is no way we can review it.

> I feel like people are keeping a stiff foot for far too long.

Walter is the critical point on the critical path at the moment.

> Stagnation in development is bad enough, but this image really hurts me. I count on you, I want you guys to shine. I see all these talented musicians, but the conductor is not on his podium.

That is a very apt analogy, you should talk to the conductor. I hope to announce the answer i have for this soon, but it will be by necessity a high latency process.

> Come on, friends, you've cracked harder nuts. Please :-)

Indeed, the next move is Walter's, if he chooses to not make it, so be it.

On Wednesday, 24 October 2018 at 22:26:48 UTC, Neia Neutuladh wrote:
> On Wed, 24 Oct 2018 13:51:11 -0700, Walter Bright wrote:
>> It is documented here: https://issues.dlang.org/show_bug.cgi?id=19097
>> 
>> If you don't understand it, feel free to ask.
>
> People are asking for a spec update with specification-level clarity and precision.

We're not even asking for that! github.com/dlang/dlang.org/pull/2453 is mostly the "how do you use this feature, and why is that important", not the nitty gritty. Without the "how to use" and "why" it is impossible to differentiate the wrong nitty gritty from the right nitty gritty (which is what reviewing is).

On Wednesday, 24 October 2018 at 20:36:03 UTC, Walter Bright wrote:
> On 10/23/2018 7:38 PM, Nicholas Wilson wrote:
>> Because we do not understand the changes,
>
> Ask what it is you do not understand.

" is [dlang.org#2453] an accurate description?"

On Wednesday, 24 October 2018 at 20:51:11 UTC, Walter Bright wrote:
> On 10/23/2018 10:20 PM, Neia Neutuladh wrote:
>> The change seems small to you, so documenting it at the same time as the
>> PR is out doesn't seem that important. But it still needs to be
>> documented, and people are asking for the documentation to help with
>> reviewing the PR. Why not just write the documentation? It's been three
>> months.
>
>
> It is documented here: https://issues.dlang.org/show_bug.cgi?id=19097

For the last time: BUGZILLA IS NOT DOCUMENTATION!!!!!!!!!

> If you don't understand it, feel free to ask.

I have: https://github.com/dlang/dlang.org/pull/2453#issue-210353863

On 10/23/18 6:10 PM, Walter Bright wrote:
> On 10/23/2018 8:10 AM, Steven Schveighoffer wrote:
>> So, here is one other thing I want to say. This took me HOURS to find, and narrow down. Not because I don't understand the concepts behind dip1000, but because the compiler has fully inserted so many hidden scopes, I don't know what the actual code it's compiling is. One big problem I think with dip1000 is simply that it's nearly impossible to understand where the issues are. Like I said at the end of the post above, the result of allowing compiler inference of dip1000 is that your whole program is simply marked unsafe, and you have absolutely no idea where it is. You can't even guess, because scope just shows up where you never typed it. Given that you NEED this functionality on templates, it's going to result, IMO, in people either not using dip1000, or giving up and adding @trusted: to the top of their file. This is going to be horrible if we can't find a way to either require scope instead of inferring it in some cases, or create a way to diagnose where the blasted problem actually is. Maybe something to say "I expected this call to be @safe, why isn't it".
> 
> My improvements to DIP1000 are completely dead in the water due to lack of interest. It's impossible to make Phobos DIP1000 compatible if nobody is willing to approve the improvements.
> 
> https://github.com/dlang/dmd/pull/8504

I know this debate is continuing. But that PR has nothing to do with the problem I'm having (what this post is really about). I'm not returning anything via the first parameter. Just for kicks, I downloaded your PR branch, and it still has the same problem with somehow assuming something is scope. So can you address this problem at all?

Alarmingly, the current dlist builds fine with dip1000, even though it conceptually is the same thing -- it's just that the casts destroy any tracking of lifetimes (or so my theory goes), so it builds happily. We don't want people to resort to opacity and casts to get around dip1000.

-Steve