<div dir="ltr"><div dir="ltr">On Thu, Mar 26, 2020 at 12:15 AM Steven Schveighoffer via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In response to Walter's response to ag*, I would say that there is a <br>
fatal problem with automatically allowing extern(C) function prototypes <br>
(and really, anything that does not mangle @safe) to be default @safe.<br>
<br>
The reason is simple -- the change is silent and automatically marks <br>
everything @safe that has not been checked.<br>
<br>
I would argue that if the compiler is going to make things @safe by <br>
default, then things that are not marked and are not @safe should not <br>
compile AT ALL COSTS. Otherwise the value of @safe is completely lost.<br>
<br>
The DIP should be rejected IMO unless all functions with no mechanism to <br>
mangle @safe into the name (e.g. extern(C), extern(C++), etc) that have <br>
no implementation are either:<br>
<br>
a) required to be marked, or<br>
b) default @system.<br>
<br>
Everything else in the DIP is possibly annoying to deal with but at <br>
least doesn't silently destroy the meaning of @safe.<br>
<br>
I will note that I support the notion of @safe by default. I would be in <br>
favor of the DIP as long as this fatal flaw is not included.<br>
<br>
-Steve<br></blockquote><div><br></div><div>I'm really on board with this. My feeling though is that it should be b; extern(Language) should be @system by default, except maybe extern(Rust), which nobody has ever asked for.</div></div></div>