DIP1028 - Rationale for accepting as is

[Walter Bright]

On 5/25/2020 7:04 PM, Johannes Loher wrote:
> 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?

Yes, for reasons I carefully laid out.

 > no clues whatsoever

He can look at unattributed declarations.

The whole debate boils down to "is greenwashing better, more honest, more 
debuggable than leaving things unattributed?" No on all three accounts.