Preventing another 1028

[Paulo Pinto]

On Thursday, 28 May 2020 at 09:56:11 UTC, Timon Gehr wrote:
> On 28.05.20 09:52, Daniel Kozak wrote:
>> On Thu, May 28, 2020 at 2:10 AM Bruce Carneal via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote
>>>
>>> DIP 1028 is unsound.
>> 
>> No it is not
>> ...
>
> That's technically true. The issue is an existing hole in 
> @safety, but one that gets exacerbated by a change in defaults.
>
> https://dlang.org/spec/memory-safe-d.html
>
> "Therefore, the safe subset of D consists only of programming 
> language features that are guaranteed to never result in memory 
> corruption."
>
> `extern(C)` is not such a feature, so the existing behavior is 
> in violation of the specification.
>
> The hole can be plugged by changing a couple of lines of DMD's 
> source code. Instead, Walter is now defending the @safety hole.
>
> This is sending a weird message. Is this how we are going to 
> deal with holes in `@safe` going forward? If so, what is the 
> justification for the additional overhead necessary to make 
> code `@safe` the proper way? At that point it seems like a 
> reasonable solution to just opt out using `@system:` and/or use 
> `@safe` merely as a linting mechanism and `@trusted` as a way 
> to make the compiler shut up when it is convenient, which is 
> exactly what Walter is worried about.
>
> I think it is important that we can explain `@safe` with a 
> straight face.

Specially when all other modern system programming language do 
mark such external code as unsafe. Even Zig has a couple of open 
tickets regarding this.

D will need a very good marketing strategy to sell itself to 
security conscious crowd if this DIP is integrated this way.

Consider that D wasn't even mentioned on Chromium security post 
regarding what languages the team might consider to improve its 
security surface.