Typical security issues in C++: why the GC isn't your enemy

[areYouSureAboutThat]

On Monday, 12 December 2022 at 23:18:13 UTC, Timon Gehr wrote:
> On 12/12/22 12:07, Siarhei Siamashka wrote:
>> 
>> You have my 100% support here. But the tricky thing is that 
>> the majority of the current D language community seems to 
>> disagree with us, as evidenced by the apparent rejection of 
>> DIP 1028. And we should do a much better job convincing them 
>> to change their mind.
>
> Sorry, but this is a really bad take. DIP 1028 wanted to make 
> extern(C) prototypes `@safe` by default, which is essentially 
> the only criticism it attracted. [1] Walter then decided to 
> pull the DIP entirely. It's not on the community.
>
>
> [1] `@safe` on an `extern(C)` prototype is currently equivalent 
> to `@trusted`. DIP 1028 was therefore "@trusted by default". A 
> really bad default and one that would make existing _unsafe_ 
> code `@safe` implicitly.

The problem with D (which has always been its problem, and likely 
always will be its problem), is that it 'defaults' to allowing 
the programmer to shoot themselves in the foot, at any time, and 
typically without warning (i.e. it defaults to 'ease of use' over 
safety).

That's what 'ease of use' means in D (the same as it means in C - 
trust the programmer).

This is why it's not mentioned by NSA I suspect (assuming they've 
even heard of it). NSA do NOT want you to use languages that 
'implicately trust' the programmer to get memory safety correct.

'ease of use' (I suspect) is what attracts some to D. But for 
others, it's @safe that attract them to D. Both are at opposite 
ends of the spectrum.

So how to please people that are at opposite ends of the spectrum?

You give them 'the option', to opt-in or opt-out. It's that 
simple.

So how about a compile time, commandline switch, that (warns or 
fails) when @safe code is calling @trusted code?

Basically, I'm, saying to the compiler -> "if it's not @safe, I 
do not 'trust' it."