DIP1028 - Rationale for accepting as is
Gregory
g.thompson.1892 at gmall.com
Tue May 26 11:02:55 UTC 2020
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.
>
> > 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.
I think this is what's the most frustrating part. You aren't
actually taking criticism if you cherry-pick what you reply to.
More information about the Digitalmars-d-announce
mailing list