DIP1028 - Rationale for accepting as is

[Steven Schveighoffer]

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