DIP1028 - Rationale for accepting as is

[Bruce Carneal]

On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
> 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.

A direct response to Andre's thorough critique of your reasoning 
would be appreciated.

>
> > no clues whatsoever
>
> He can look at unattributed declarations.

Again, as many have noted, putting a coverage problem like this 
on the programmer is problematic.

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

Greenwashing is bad.  En masse greenwashing by the compiler, as 
mandated by the DIP currently, is really bad.