DIP1028 - Rationale for accepting as is

[Bruce Carneal]

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?