I approved DIP1036e

[Meta]

On Sunday, 21 January 2024 at 17:37:41 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 22/01/2024 1:35 AM, Dom DiSc wrote:
>>     Sadly, because it's easier bikeshed, especially when the 
>> reviewer
>>     doesn't actually understand the code, most code reviews 
>> turn into
>>     nit-picks focusing on sub-optimal but ultimately 
>> insignificant
>>     deviations from the reviewers stylistic preferences, all 
>> in the name
>>     of "legibility". The single best way to derail a 
>> conversation on
>>     code reviews is to bring up the topic of ... line length.
>> 
>> Oh please. Everybody submitting a PR can easily run dfmt on 
>> it. This done there should be no more "too long lines", 
>> "multiple expressions in one line", "not correct indented 
>> code", "curly braces not on their own line", etc. pp. If 
>> someone submit PRs without running dfmt, (s)he should be 
>> advised to do so. End of discussion.
>
> Yes, that has been added to the PhobosV3 proposal by Adam.
>
> I also suggested that we automate it as part of the CI. Because 
> who has time to care about white space at the end of a line? No 
> thanks.

Yes, yes, and yes. At work we have a linter that IS integrated 
into the CI pipeline, and a formatter that is NOT, for some 
unfathomable reason. Every time one of my PRs fails the CI 
pipeline because I forgot to run the formatting tool before 
pushing, I want to scream. Just automate it and a whole class of 
PR nitpicks/arguments disappears, and everyone is better off.