On Wednesday, 27 May 2020 at 15:22:54 UTC, Ethan wrote:
> Distracted boyfriend format: https://imgflip.com/i/430bdh

This one is quite telling what actually happened. The only thing that is missing is adding Walters face on that guy. I was sure that DIP 1028 would have to take another round because there were a few open issues with this DIP that many pointed out. Instead DIP 1028 was rushed and of course Walter really wants this DIP to go through as it is "the new hot chick in town", which he has said himself that safe by default is one of the highest priorities. So things were rushed ....

On Thursday, 28 May 2020 at 12:16:37 UTC, IGotD- wrote:
> On Wednesday, 27 May 2020 at 15:22:54 UTC, Ethan wrote:
>> Distracted boyfriend format: https://imgflip.com/i/430bdh
>
> This one is quite telling what actually happened. The only thing that is missing is adding Walters face on that guy. I was sure that DIP 1028 would have to take another round because there were a few open issues with this DIP that many pointed out. Instead DIP 1028 was rushed and of course Walter really wants this DIP to go through as it is "the new hot chick in town", which he has said himself that safe by default is one of the highest priorities. So things were rushed ....

The DIP was not rushed. It went through the same steps as every other DIP.

https://github.com/dlang/DIPs

On Thursday, 28 May 2020 at 13:28:00 UTC, Mike Parker wrote:
> On Thursday, 28 May 2020 at 12:16:37 UTC, IGotD- wrote:
>> On Wednesday, 27 May 2020 at 15:22:54 UTC, Ethan wrote:
>>> Distracted boyfriend format: https://imgflip.com/i/430bdh
>>
>> This one is quite telling what actually happened. The only thing that is missing is adding Walters face on that guy. I was sure that DIP 1028 would have to take another round because there were a few open issues with this DIP that many pointed out. Instead DIP 1028 was rushed and of course Walter really wants this DIP to go through as it is "the new hot chick in town", which he has said himself that safe by default is one of the highest priorities. So things were rushed ....
>
> The DIP was not rushed. It went through the same steps as every other DIP.
>
> https://github.com/dlang/DIPs

I think everyone can agree that there's a huge conflict of interest when the person creating the DIP is also the one that is suppose to be criticising it and determines whether it is accepted or not. There's a huge difference in the level of detail, care, and explanation between one of Walter's DIPs and the DIPs done by other individuals.

As is with the case with DIP1028, no where in the DIP is greenwashing mentioned. There's barely a section explaining the rationale as to why extern(C) should be @safe. Walter purposefully did not explain his rationale behind the motive to make that change. He only explained it after the DIP had already been accepted. So it was never something anyone could criticise in the entire process because his DIPs don't have to explain. It just has to state what it's doing and that's not what a DIP should be; it should explain why so it can be criticised properly.

There's a clear problem with the current DIP process. DIP1028 has made that clear.

On Thursday, 28 May 2020 at 14:56:14 UTC, Gregory wrote:
>
>
> There's a clear problem with the current DIP process. DIP1028 has made that clear.

I disagree. The process itself is working as intended.

On Thursday, 28 May 2020 at 16:27:56 UTC, Mike Parker wrote:
> On Thursday, 28 May 2020 at 14:56:14 UTC, Gregory wrote:
>>
>> There's a clear problem with the current DIP process. DIP1028 has made that clear.
>
> I disagree. The process itself is working as intended.

Which is why the process is problematic and needs to be changed.

On Thursday, 28 May 2020 at 16:35:09 UTC, Adam D. Ruppe wrote:

>
> Which is why the process is problematic and needs to be changed.

Again, I disagree. The *process* is not problematic. The issue people are having right now is with the assessment of DIPs written by the language maintainers. That's separate from the review process itself.

On Thursday, 28 May 2020 at 16:35:09 UTC, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 16:27:56 UTC, Mike Parker wrote:
>> On Thursday, 28 May 2020 at 14:56:14 UTC, Gregory wrote:
>>>
>>> There's a clear problem with the current DIP process. DIP1028 has made that clear.
>>
>> I disagree. The process itself is working as intended.
>
> Which is why the process is problematic and needs to be changed.

For most DIPs we have two nominally impartial experts looking out for the interests of the community.  In the case of 1028 we only had 1, Atila.

This is a problem with the process that can and should be fixed.

On Thursday, 28 May 2020 at 16:50:52 UTC, Bruce Carneal wrote:
> For most DIPs we have two nominally impartial experts looking out for the interests of the community.  In the case of 1028 we only had 1, Atila.
>
> This is a problem with the process that can and should be fixed.

No, this is where y'all are getting wrong. The process led to a review board of two. Or, essentially one in this case since the author was on the board and thus unable to be impartial.

The board is the area that needs expansion. The process that gets a DIP in front of and away from the board will not change if the number of board members increases/members recuse themselves for impartiality reasons/etc.

On Thursday, 28 May 2020 at 16:48:41 UTC, Mike Parker wrote:
> On Thursday, 28 May 2020 at 16:35:09 UTC, Adam D. Ruppe wrote:
>
>>
>> Which is why the process is problematic and needs to be changed.
>
> Again, I disagree. The *process* is not problematic. The issue people are having right now is with the assessment of DIPs written by the language maintainers. That's separate from the review process itself.

That's part of it. But at least some people also also would like to change the fact that in the end, the decision is made only by 2 people, especially if the proposal is made by one of these 2 people. The reason is that it just is very difficult to make an objective decision about your own proposal and only having to convince one person is a lot easier than having to convince 2. People feel that DIP1028 would probably not have been accepted if we had a stricter process in that regard.

On Thursday, 28 May 2020 at 12:16:37 UTC, IGotD- wrote:
> he has said himself that safe by default is one of the highest priorities.

I've stated my position previously around these parts, but in summary:

@safe and @pure by default is really important for asynchronous code, and I'm all for it. I also think it's a big enough change that it warrants a new major language version as it will provably break old code and backwards compatibility will be a nightmare to maintain.

But there's a meme for every occasion, and my view on the outright hack to apply @safe to D2 code via this DIP is summarised with: https://media.giphy.com/media/dCdGHgF7yFHFK/200.gif

@safe and @pure is to guarantee my programmers don't write bad code. @safe applied to code DMD cannot parse is leaving a hole in the language security that needs to be measured in Astronomical Units.