@safe/DIP1028 explained in meme form

Patrick Schluter Patrick.Schluter at bbox.fr
Thu May 28 20:19:39 UTC 2020


On Thursday, 28 May 2020 at 19:56:53 UTC, Gregory wrote:
> On Thursday, 28 May 2020 at 17:38:15 UTC, Mike Parker wrote:
>> On Thursday, 28 May 2020 at 17:21:05 UTC, Gregory wrote:
>>> [...]
>>
>> I repeat: the process is working as intended. That no one 
>> succeeded in convincing the DIP author to revise the DIP is 
>> not a failure of the process. That the decision to approve is 
>> unpopular is not a failure of the process.
>>
>> Whether or not the language maintainers should be evaluating 
>> their own proposals is an issue with the decision making, not 
>> with the entire process.
>
> Let me try and make it simpler for you so you can understand, 
> answer this question only, and if you talk about anything about 
> the process you've failed.
>
> The fact a major part of the reasoning behind DIP1028 (aka 
> greenwashing) wasn't brought up for criticism as part of the 
> debate until after the DIP was already accepted, do you see 
> this as a problem? Yes or no?

The issue was brought up during the discussion round. The thing 
was, and that was why people were so frustrated, the DIP was 
accepted as is WITHOUT taking up any feedback. This, per se, was 
not a fault in the process, but on the DIP author to ignore the 
feedback.

>
>> That no one succeeded in convincing the DIP author to revise 
>> the DIP is not a failure of the process.
>
> Read this for a second. The *AUTHOR* of a DIP wasn't convinced 
> their own idea wasn't good enough to write a DIP for. This is 
> the equivalent of having a jury start with a presumption of 
> guilt, where the jury is the victim.



More information about the Digitalmars-d mailing list