DIP1028 - Rationale for accepting as is

[Jonathan M Davis]

On Wednesday, May 27, 2020 8:13:52 PM MDT Bruce Carneal via Digitalmars-d-
announce wrote:
> On Thursday, 28 May 2020 at 01:14:43 UTC, Jonathan M Davis wrote:
> > On Friday, May 22, 2020 12:09:16 PM MDT rikki cattermole via
> >
> > Digitalmars-d- announce wrote:
> >> [...]
> >
> > Except that the linker matters a great deal in this discussion
> > with regards to extern(D) functions, because @safe and @trusted
> > are part of the name mangling for extern(D) functions. That
> > means that if an extern(D) function declaration's attributes do
> > not match its definition, then you'll get a linker error. So,
> > treating non-extern(D) function declarations as @safe by
> > default isn't necessarily a problem (though it would certainly
> > work to just treat all function declarations as @system by
> > default rather than treating extern(D) function declarations
> > differently). The cases where non-extern(D) function
> > declarations weren't actually @safe would be caught during the
> > linking process. Sure, it would be nice if it were caught
> > sooner, but you don't end up with them being invisibly treated
> > @safe when they're not like we're going to get with DIP 1028.
> >
> > [...]
>
> I remember reading a suggestion that additional linker symbols be
> emitted to carry the attribute and possibly type information
> while leaving the ABI untouched.  Was this found to be
> impractical?

Steven suggested something along those lines. I don't know how practical it
would or wouldn't be, but I don't think that Walter even responded to the
idea.

Regardless, even if it worked perfectly, all such a solution would deal with
would be the cases where you have a non-extern(D) function which is actually
written in D and had its function body marked as @safe (and thus was
verified to be @safe). Such functions definitely exist, but the main problem
is really non-extern(D) functions which are actually written in C or C++ or
whatnot. They won't have been checked for @safety.

Right now, such declarations are treated by the compiler as @system by
default, because it cannot check them for @safety, whereas with DIP 1028, it
will then treat them as @safe in spite of the fact that it can't check them
for @safety simply because Walter thinks that it would be too exceptional to
treat them differently from the general rule of @safe by default and that if
they're left as @system, too many people will just slap @trusted on their
code as a whole to get the compiler to shut up.

But regardless of whether DIP 1028 is the correct decision, the problem
remains that your typical extern(C) function cannot be checked for @safety
by the compiler, because it was compiled by a C compiler. The question then
is just how the D compiler should treat them, and that's the main point of
contention. There may be solutions like Steven suggested which would deal
with edge cases where the implementation is in D but the linkage isn't, but
ultimately, they're just edge cases.

- Jonathan M Davis