DIP1028 - Rationale for accepting as is

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu May 28 01:14:43 UTC 2020


On Friday, May 22, 2020 12:09:16 PM MDT rikki cattermole via Digitalmars-d-
announce wrote:
> It kept being swapped about in the discussion thread, so I have been a
> little on edge over people using non-extern(D). Because linkage doesn't
> mean anything to anything but to cpu and linker in this discussion.

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.

However, of course, with non-extern(D) declarations, even if the function
definition is actually written in D, the fact that the function body was
checked is not transmitted via the linking process, because it doesn't end
up in the name mangling. So, the linkage used has a huge impact on whether
you can rely on the @safe attribute on the function declaration actually
meaning anything about whether the body was verified by the compiler.

- Jonathan M Davis





More information about the Digitalmars-d-announce mailing list