DIP1028 - Rationale for accepting as is

[Andrei Alexandrescu]

The DIP is trying to accomplish (copied from its Rationale):

A. Costs of unsafe code have become ever more apparent and expensive, 
and @safe has grown more capable. Users expect safety to be opt-out, not 
opt-in.

B. Most code should be naturally safe, and system code should be 
relatively rare. It makes sense that the common case - safe code - 
should be the default and not require an annotation.

Any judgment on the regime of extern(C) functions should be judged as 
follows: "To what extent does the chosen regime of C functions push the 
rationale forward?"

The decision fails to support (A) because it keeps safety of C functions 
opt-in. It also fails to support (B) because it keeps code that does not 
require an annotation yet is not safe.

A good process would simply go back to the drawing board once the matter 
is exposed. It is very easy for reasonable people to agree that there is 
no part of rationale that justifies the decision. Either redefine the 
rationale (adding e.g. "keep some applications compilable without 
change" as an important goal), or change the handing of C functions.

The core argument recently detailed is:

A. Define "greenwashing" as a quick workaround to get code to work.
B. Describe in excruciating detail the experience with Java exceptions.
C. Establish a vague analogy with people placing @trusted on C declarations.
D. Assume without stating that the user would do "greenwashing" but the 
compiler doing it surreptitiously is somehow exempt.
E. Conclude that extern(C) code must be trusted.

This argument is already a smorgasbord of fallacies. It iterates a good 
subset of https://en.wikipedia.org/wiki/List_of_fallacies, and I am not 
kidding when I say a few edits to those pages with backreferences to 
this thread would be appropriate.

To start:

False analogy: making extern(C) function system is analogous with the 
Java exeception specification debacle.

https://en.wikipedia.org/wiki/Argument_from_analogy#False_analogy

This is a false analogy belying what seems to be a misunderstanding of 
the problem with Java exceptions: it was a maintenance problem, not an 
introduction problem.

The matter was, during maintenance, routinely code would change the set 
of exceptions they threw. So maintainers would need to touch code that 
didn't belong to them. There was also no "shrinking" of exception 
specification lists because the compiler does not enforce 
larger-than-necessary lists. So these lists would just grow forever 
during maintenance, with no real information attached and no usefulness.

None of these apply to @safe. Functions don't change their safety with 
ease, and when they do you definitely want to be informed. There's no 
growth of attributes for obvious reasons.

To the extent the analogy applies, the burden of proof is entirely on 
the DIP, and in this case the differences are so many and large, it's 
not worth making the argument by analogy in the first place.

The excruciatingly long discussion of Java exception specifications is 
an instance of another fallacy, misleading vividness:

http://nizkor.com/features/fallacies/misleading-vividness.html

It was expected that any of the bad things about exceptions would count 
as yet another good argument for the DIP. This constructs a textbook 
straw man:

https://en.wikipedia.org/wiki/Straw_man

So the argument constructs a straw man (Java exception specifications), 
discusses it at length on a long tangent (misleading vividness), to then 
conclude (by false analogy) that we don't want extern(C) functions to be 
@system.

What's missing is, of course, an explanation on how the decision 
supports the very rationale of the DIP. Which it doesn't - it factually 
works straight against it.

I decided to make this public only once the second boot fell (read on):

On 5/23/20 11:28 PM, Walter Bright wrote:
> I'd like to emphasize:
> 
> 1. It is not possible for the compiler to check any declarations where 
> the implementation is not available. Not in D, not in any language. 
> Declaring a declaration safe does not make it safe.

Strawman: https://en.wikipedia.org/wiki/Straw_man

Nobody asked for that, and listing it as an argument is pointing at a 
strawman.

> 2. If un-annotated declarations cause a compile time error, it is highly 
> likely the programmer will resort to "greenwashing" - just slapping 
> @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've 
> all done it. Sometimes even for good reasons.

Nirvana fallacy: https://en.wikipedia.org/wiki/Nirvana_fallacy

"Electric cars still use polluting materials and processes, so let's 
continue making gasoline cars."

"People will add workarounds to code, so let's accept the dangerous code 
anyway."

> 3. Un-annotated declarations are easily detectable in a code review.

Proof by assertion: https://en.wikipedia.org/wiki/Proof_by_assertion

(Um... there's no grep for "find me all un-annnotated declarations")

> 4. Greenwashing is not easily detectable in a code review.

Proof by assertion: https://en.wikipedia.org/wiki/Proof_by_assertion

(Um... grep '@safe|@trusted')

> 5. Greenwashing doesn't fix anything. The code is not safer. It's an 
> illusion, not a guarantee.

Shifting the burden of proof from the DIP to the reviewer: 
https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)

The DIP needs to prove it does not perform greenwashing itself. Which it 
factually does - it paints all C code as safe with no user intervention.
"Quod licet bovis non licet Iovis" much? That smacks of special pleading:

https://en.wikipedia.org/wiki/Special_pleading

Of course we have the strawman: https://en.wikipedia.org/wiki/Straw_man. 
Nobody asked for greenwashing.

> 6. If someone cares to annotate declarations, it means he has at least 
> thought about it, because he doesn't need to. Hence it's more likely to 
> be correct than when greenwashed.

So... requiring adding annotations to extern(C) is good?

> 7. D should *not* make it worthwhile for people to greenwash code.

Proof by assertion: https://en.wikipedia.org/wiki/Proof_by_assertion

No accounting for the fact that the very built-in rule does exactly 
greenwashing as the post seems to define it.

> It is, in a not-at-all obvious way, safer for C declarations to default 
> to being safe.

In ensemble, all this adds up to a good Kettle logic fallacy:

https://en.wikipedia.org/wiki/Kettle_logic

For the record, I think adoption of this rule works against the very 
thing that the DIP is trying to accomplish and will also cause a serious 
PR blow.