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.
