In response to Walter's response to ag*, I would say that there is a
fatal problem with automatically allowing extern(C) function prototypes
(and really, anything that does not mangle @safe) to be default @safe.
The reason is simple -- the change is silent and automatically marks
everything @safe that has not been checked.
I would argue that if the compiler is going to make things @safe by
default, then things that are not marked and are not @safe should not
compile AT ALL COSTS. Otherwise the value of @safe is completely lost.
The DIP should be rejected IMO unless all functions with no mechanism to
mangle @safe into the name (e.g. extern(C), extern(C++), etc) that have
no implementation are either:
a) required to be marked, or
b) default @system.
Everything else in the DIP is possibly annoying to deal with but at
least doesn't silently destroy the meaning of @safe.
I will note that I support the notion of @safe by default. I would be in
favor of the DIP as long as this fatal flaw is not included.
-Steve
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.
There's also the matter that with this DIP we REALLY need @trusted expressions or scopes. It's inappropriate that you need to tag an entire function when you just want to make one unsafe call and the few lines of surrounding context assert any safety requirements.
I also think that the names make little sense in a @safe-by-default world, and really there should only be @unsafe. It's not necessary to have @system AND @trusted.