Rationale for accepting DIP 1028 as is

[Jonathan M Davis]

On Wednesday, May 27, 2020 3:30:32 AM MDT Andrei Alexandrescu via Digitalmars-
d-announce wrote:
> On 5/27/20 1:49 AM, Walter Bright wrote:
> > On 5/26/2020 9:31 AM, Bruce Carneal wrote:
> >> Currently a machine checked @safe function calling an unannotated
> >> extern C routine will error out during compilation. This is great as
> >> the C routine was not machine checked, and generally can not be
> >> checked.  Post 1028, IIUC, the compilation will go through without
> >> complaint.  This seems quite clear.  What am I missing?
> >
> > Nothing at all.
>
> That means safe by default is effectively loosening D's notion of safety.
>
> This DIP must go.

Which is exactly what most of us have been arguing for weeks (months?). It
either needs to go or be ammended so that non-extern(D) declarations
continue to be treated as @system instead of automatically becoming @safe
with the DIP.

The result of all of that arguing is that Walter accepted the DIP and then
started this thread as his more detailed reply when there were a ton of
complaints about the DIP's acceptance - and of course, you've already read
and replied to his reasoning.

As far as I can tell, Walter understands the issues but fundamentally
disagrees with pretty much everyone else on the issue. He seems to think
that weakening @safe is worth doing, because it will ultimately mean that
more code will be treated as @safe and mechnically checked by the compiler,
whereas most everyone else thinks that weakening @safe is unacceptable. But
since Walter managed to convince Atila, the DIP has been accepted.

- Jonathan M Davis