Rationale for accepting DIP 1028 as is

[jmh530]

On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
> [snip]
>
> Nothing at all.
>
> But I doubt there is much legacy non-compiling code around.

I cannot speak for all the code out there, but I know of at least 
one binding out there [1] that will need to get updated in light 
of this DIP.

I also put together a wrapper [2] that sits on top of that 
binding (many years ago and no idea if the wrapper still works (I 
see no reason why the binding wouldn't), so this probably does 
count as legacy code) and calls the binding functions with 
templates and no safety annotations. So theoretically, after the 
DIP is accepted and without any other changes, nlopt.d becomes 
@safe and the binding that calls it also becomes @safe and any 
user code that calls it becomes @safe.

***************************

On a separate note, the current definition of @safe is that you 
cannot call @system functions. This prevents calling unannotated 
extern(C) prototypes from @safe code.

Ignoring DIP 1028 for a second, would you consider changing the 
rules so unannotated extern(C) prototypes are @safe instead of 
@system without any other change? Just this change by itself 
would mean that @safe functions can call unannotated extern(C) 
prototypes. Obviously this by itself could be rejected for 
special casing. However, I think the underlying question is 
should they be safe (ignoring @safe) or not. An argument made 
previously is that they should be safe and thus @safe. However, I 
think the overwhelming belief is that they are not safe and thus 
should not be @safe by default.

 From this perspective, you could think of the DIP as doing two 
things. 1) it makes unannotated extern(C) prototypes @safe 
instead of @system and 2) it makes all other unannotated 
functions @safe instead of @system. The big focus is clearly on 
#1. You can assume that most people agree with you on #2 and thus 
focus the debate on #1

So, do you think unannotated exten(C) prototypes safe? If you 
think they are safe, then there is no issue with making them 
@safe by default. However, if you do not think they are safe, 
then it raises serious concerns to make them @safe by default.

[1] 
https://github.com/DlangScience/nlopt/blob/master/source/nlopt.d
[2] https://github.com/jmh530/nloptd/blob/master/source/nloptd.d