DIP1028 - Rationale for accepting as is

[Johannes Loher]

On Tuesday, 26 May 2020 at 01:16:49 UTC, Walter Bright wrote:
> On 5/24/2020 5:56 PM, Timon Gehr wrote:
>> It's only greenwashing if it's misleading. Putting @safe is a 
>> lie, putting @trusted is honest.
>
> It is not honest unless the programmer actually carefully 
> examined the interface and the documentation to determine if it 
> is a safe interface or not. For example, labeling memcpy() with 
> @trusted is not honest.
>
> Forcing people to add uncheckable annotations is a path to 
> convenience, not honesty.

This has already been repeated over and over again but I'll do it 
once more:

If people cannot check the code (or get enough confidence in 
another way), they really shouldn’t annotate it with @trusted but 
with @system instead. If they annotate it with @trusted anyways, 
it is their own fault. And at least in that case they are lying 
and not the compiler. Also if something bad actually happens, 
they can at least search for „high risk areas“ (@trusted 
declarations).

Just consider the following situation:

A (maybe inexperienced) programmer needs to call an existing C 
function from D code. Because no bindings exist yet, he creates 
them himself. He does not add any annotations regarding safety. 
Now he uses this function in @safe code and he uses it in a way 
that actually creates a memory corruption (the function is not  
safe, but the developer does not know about that).

Now let's compare the two different options:

1. With DIP1028 in its current form, the code will compile and a 
memory corruption will actually happen. The problem might be 
extremely difficult to track down for the developer because he 
has no clues whatsoever where to start looking.

2. With one of the solutions that were presented, the code will 
not compile as it is. According to your argument of 
„convenience“, the developer will probably just mark the function 
incorrectly as @trusted which makes the code compile. The memory 
corruption will happen. However, even if the developer did not 
think much about potential safety issues when adding @trusted to 
the function, he now still remembers that he did that (it was a 
conscious decision, even if it was a careless and lazy one). He 
has a clear point to start looking for the reason of the memory 
corruption.

Do you honestly think option 1 is better?