Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Jonathan M Davis]

On Friday, March 27, 2020 1:04:49 AM MDT rikki cattermole via Digitalmars-d 
wrote:
> On 27/03/2020 12:16 PM, Jonathan M Davis wrote:
> > On Thursday, March 26, 2020 4:54:53 PM MDT rikki cattermole via
> > Digitalmars->
> > d wrote:
> >> And then there is .di files which complicates the matters further.
> >>
> >> But I agree with you.
> >>
> >> If the compiler _cannot_ or has _not_ confirmed it is @safe, a function
> >> should not be marked as @safe and be callable.
> >
> > Actually, .di files don't complicate things much. non-extern(D)
> > declarations have to be treated the same no matter where they are, and
> > anything with a function body in a .di file is the same as if it were
> > in a .d file. The only real difference is that you then have extern(D)
> > declarations added into the mix, and because whether they're @safe,
> > @trusted, or @system is part of their name mangling, they cannot link
> > if they don't have the same @safety level as the corresponding function
> > definition (which was verified by the compiler if it's @safe). So, the
> > compiler can treat extern(D) function declarations as @safe by default
> > just like it does function definitions without there being a problem.
> > The only real issue is if the declaration and definition don't match,
> > which is a problem regardless of what the default @safety level is.
> >
> > - Jonathan M Davis
>
> The problem that concerns me is not its linkage or where that is
> occurring, its the fact that we treat .di files as trusted. We as a
> community have long said don't modify these files generated by the
> compiler.
>
> If it is generated by the compiler then the checks that have been said
> to have occurred should have occurred. For example @safe on a function
> declaration without a body.
>
> But on a regular D file, these checks have not been checked yet. As
> these files come from a human being and not a compiler. Hence if a body
> isn't present, it cannot be @safe. It has not been verified.
>
> Which means that in a .d file what is allowed is less than a .di file.
> If we follow this line of thought it creates a problematic situation.

I really don't get what you're trying to say.

Regardless of how a .di file was created, if an extern(D) function
declaration in it is @safe (be it because the compiler implicitly treats it
as @safe or it's explicitly marked with @safe), then it will only link if
the corresponding function definition is @safe. So, any attribute mismatches
will be caught when you link your program. As such, there is no way for
there to be a hole in @safe due to using a .di file with an extern(D)
function. Because the function definition will have been verified by the
compiler, and it must have the exact same set of attributes as the function
declaration for the program to link, the function _was_ verified even if
your program imports the .di file rather than the .d file.

You can of course have linker errors due to the .di and .d files not
matching, but that happens with _anything_ that affects the function
signature. It's not at all unique to @safe.

- Jonathan M Davis