Rationale for accepting DIP 1028 as is

[Jonathan M Davis]

On Thursday, May 28, 2020 2:50:44 AM MDT Daniel Kozak via Digitalmars-d-
announce wrote:
> On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
>
> Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
> > As far as I can tell, Walter understands the issues but fundamentally
> > disagrees with pretty much everyone else on the issue.
>
> I do not think so, the issue is, that there could be more people who
> agree with Walter (like me),
> but because we agree we do not participate.

There may be some silent people who agree, but in all the discussions on
this DIP, almost no one has agreed with Walter on this. It has not been a
back and forth discussion with some on Walter's side and some against. It's
been pretty much everyone against Walter. He did unfortunately manage to
convince Atila, so the DIP has been accepted, but based on the discussions,
I think that you may be the only person I've seen say anything positive
about the DIP treating extern(C) functions as @safe. The fact that @safe
becomes the default has garned some debate with some in favor and some
against (with most seeming to be in favor), but the idea of making extern(C)
declarations @safe by default has been almost universally considered a bad
idea by anyone who has responded on the topic. Most DIPs do not get anywhere
close to this level of negative feedback.

> > But since Walter managed to convince Atila, the DIP has been accepted.
>
> So everything is OK right?

Everything is okay? Because a bad DIP got accepted? No, most definitely not.
Quite the opposite. With the DIP in its current state, @safe becomes a lie.
The compiler no longer guarantees that @safe code is memory safe so long as
it doesn't call any @trusted code where the programmer incorrectly marked it
as @trusted. Instead, the compiler blindly treats non-extern(D) declarations
as @safe and invisibly introduces memory safety bugs into @safe code.
Nothing about that is "OK." From the way things currently look, we're going
to have to deal with that hole in @safe in D code in the future, because the
DIP has been accepted, but it adds yet another dark corner to the language
of the sort that folks here tend to make fun of C++ for. Going forward,
we're going to have to be explaining to people why @safe code doesn't
actually guarantee that code is memory safe (in spite of the fact that
that's what it claims to do) and why any and all non-extern(D) declarations
have to be treated with extreme caution to avoid invisibly introducing
memory safety bugs into your code.

Walter is very intelligent and has made many great decisions with D, but
IMHO, this is definitely not one of them.

- Jonathan M Davis