Preventing another 1028

[Timon Gehr]

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.