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
