Greenwashing

[Lutger]

On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu 
wrote:
(...)
> If this is greenwashing, then DIP 1028 is doing it.

Using the greenwashing phrase against Walter's case for DIP 1028 
is a good rhetoric, but a weak argument and does little good I 
believe to further this conversation.

At least you did bring a definition into the mix, almost everyone 
else seems to have misunderstood what greenwashing even means!

It's exactly Walter's argument that *not* marking external 
declarations as safe by the compiler will lead to greenwashing by 
humans in practice, some programmer (not compiler!) putting safe 
declaration there to shut up the compiler. This act cannot be 
easily distinguished from careful analysis, thus misleading 
others about the memory safety of the codebase.

The compiler simply follows the rules without agenda, but a human 
has more complex intentions. Thus, there is a very big difference 
is something has been 'calculated' or 'created'. And anyone 
reading the code who is up to date about the rules will make that 
difference. This is a matter of coder psychology, not language 
lawyers. At least this is how I understand Walters argument.

The way that DIP 1028 would mislead coders about memory safety of 
the codebase is quite different. I think it boils down to 2 kinds 
of deception:

1. @safe is a sham: you'd expect safe to only allow mechanically 
verifiably code to get compiled but it doesn't. This is a PR 
problem. It's the same as @pure, you'd expect it to verify the 
referential integrity of a function, but it actually doesn't. If 
seen people invent to word 'weak purity' and 'strong purity' to 
cope with it. In practice, it's not really a problem but the PR 
around it is not nice.

2. relaxing @safe to allow unannotated externs will make it less 
useful, because in order to assess the memory safety in a 
reasonable way every part of the codebase, dependency and all 
transitive dependencies will need to be (manually) checked for 
unannotated externs, and this needs to be done every time you 
update your dependencies.

Only 1 could be thought of as greenwashing. I don't feel that's 
particularly convincing, but it also depends how safe-by-default 
is presented. There should be a huge caveat that it only applies 
to code the compiler can verify, and any unannotated code 
external to the compiler is assumed to be safe as well.

As for 2: for a lot of cases it will only be reasonable if the 
whole codebase including transitive dependencies can be 
mechanically checked on the usage of unannotated externs. Those 
should be banned in a quality check.

I know Walter hates warnings and thinks it should be in a linter, 
but this might be something the compiler could warn for and 
optionally treat as an error. The warning would also combat the 
false impression of wholesale greenwashing with a big 'told you 
so'.