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
