On 5/24/20 6:40 AM, Johannes Loher wrote:
Steven actually made a proposal regarding creating 2 different manglings for extern(C) functions that are implemented in D. Regardless of which of the solutions is taken, this could provide the same benefits that we have for extern(D) functions (linker errors if @safety does not match in the mangling). However, it sounds like a complicated solution (in an answer to him, you already mentioned that there might be technical difficulties regarding some object formats, debugging symbols, etc.) and I am not sure it's worth it. It also makes swapping out the libraries a bit weird: if you use an actual C library, it will always link but if swap to a library implemented in D, it only links if the @saftey mangling matches.
I don't think the technical difficulties make it impossible. If you can't point at the same address, point at a noop/jmp before the real address. This isn't hard.
In terms of actual C libraries, only the unsafe symbol will be defined (naturally), so marking the extern(C) function @safe (or assuming it's safe by default) is going to fail to link.
Note that "linker errors if @safety does not match" is not entirely accurate. This is ONLY the case if the prototype is @safe and the implementation is not. In all other cases, the program will link.
Next, I'd say that linker errors are reasonable for C functions -- they are not mangled, so the name is obvious (for extern(C) safe functions I would propose a really simple mangling like _d_safe_functionname). Plus, users who declare extern(C) prototypes already have to deal with linker errors because they have to name their prototypes correctly.
But I don't anticipate anyone taking up this idea (I lack the skills), it already seems DOA based on Walter's position.
-Steve
