DIP1028 - Rationale for accepting as is

[Bruce Carneal]

On Thursday, 28 May 2020 at 02:39:40 UTC, Jonathan M Davis wrote:
> 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:
>> > [...]
>>
>> 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.
>

Changing the DIP process to be 2 of 3 LMs required for acceptance 
could get us past all the "this is useless because Walter xyz..." 
road blocks.  I've a proposal in to Mike for that now.  We'll see 
how it goes.

[snip]

>
> 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

Yes.  I understand the practical limits of machine checking and 
the 1028 issues.  The edge case that I had in mind was piece wise 
replacement of C libraries with dlang reworkings and LCD FFI 
libraries written in dlang for Python and other languages.  With 
the symbol additions, ABI could be decoupled from D-specific 
capabilities.  Python and other C FFIs just work.  Dlang programs 
get broader guarantees.  Still, as you say, probably not a big 
concern.