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
