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.
