Safe by default v2

[skyline131313]

No description provided.

[mdparker]

Please add your name and contact info to the author field. You can remove Walter's.

[12345swordy]

Does this includes both body and bodiless extern functions?

[atilaneves]

This will likely break some code.

[atilaneves]

The problem with this is that a lot of those functions are actually D code.

[Bolpat]

The DIP does not (explicitly) talk about function pointer and delegate types, especially when those types are used as a function parameter or function return type.
With this DIP, which of the following two is the function declaration

void delegate() getCallback();

equivalent to?

void delegate() @safe getCallback() @safe;

or

void delegate() @system getCallback() @safe;

or some third option I could not think of?

With this DIP, which of the following two is the function declaration

void register(void delegate() callback);

equivalent to?

void register(void delegate() @safe callback) @safe;

or

void register(void delegate() @system callback) @safe;

or some third option I could not think of?

[atilaneves]

I was going to write such a DIP myself; I was waiting for -preview=dip1000 to become the default. I think that any and all declarations with no body should have explicit @safe/@trusted/@system attributes and that even considering linkage is a mistake.

[skyline131313]

How is that considered a mistake?

You are interfacing with a language that has no notion of any safety guarantees. Ignoring differences between languages and the interfaces between them is a mistake.

[atilaneves]

Because extern(C) does not mean "this is C code", it means "C linkage" and could very well be @safe D code.

[Bolpat]

The problem is, a @safe extern(C) function that is not defined in-place is not verified by the compiler – and @safe means that the compiler checked it (up to calls to @trusted). I’m no expert on this, but as far as I understand it’s about mangling. Attributes are not part of the signature of extern(C) functions. extern(C) void f() @safe; could be defined elsewhere as extern(C) void f() @system { … }. I think D needs some solution to this; Maybe I’m naïve, but it could be as easy as generating mock symbols that actually include attributes that lead to linker errors when the attributes don’t match.

At least until 2.096.0, this worked:

import a;
extern(C) void f() @safe;
void main() @safe { f(); }

module a;
extern(C) void f() @system { int* p;  int a;  p = &a; }

If you change extern(C) to extern(D), you get the link error.

[skyline131313]

Because extern(C) does not mean "this is C code", it means "C linkage" and could very well be @safe D code.

If it's @safe D code then they can just import it. It doesn't matter if it's C code, or linkage, it is still going by C's rules. Just cause safe D code can have C linkage doesn't mean it should expose a C linkage of safe.

[atilaneves]

They can indeed just import it, but it'll be extern(C) all the same. I don't know what "going by C's rules" means.

If it's D code with C linkage and it's @safe, well, it's @safe.

[Bolpat]

Importing does not safeguard you from calling a @safe annotated extern(C) declared function (e.g. from a .di file) whose definition (implementation in a .d file) is annotated @system. That’s because the annotation is not visible for the linker.
I guess the easiest way would be to allow extern(C) @safe function declarations only if they’re also definitions. The proper way would be for D to do something that safeguards you at least in simple and obvious cases.

[ntrel]

I think a more pragmatic step would be to opt in to @safe per module - @safe module foo;. That is far more flexible than a preview switch and allows mixing use of safe modules with non safe modules in the same compiler invocation. There are lots of awkward issues with changing the default. By opting in per source file those are avoided.

[mdparker]

I need a name and contact info in the Author field, please. Walter's name goes second if you're reusing content from his original DIP.

[Bolpat]

@ntrel, in which regard would @safe module foo; be different from module foo; @safe:?

[ichordev]

@ntrel, in which regard would @safe module foo; be different from module foo; @safe:?

I'm pretty sure that @safe: won't make struct or class member-functions @safe.

[dkorpel]

I'm pretty sure that @safe: won't make struct or class member-functions @safe.

It does! Unlike @nogc nothrow pure, which don't propagate through scopes.

[ntrel]

@Bolpat @safe: turns off inference of safety for templates, inferred return type functions and function literals. @safe module foo; would just change the default safety but not override inference.

[Bolpat]

@ntrel, I used templates and attributes a lot, but never stumbled on this; wow. Probably because I consider attribute: harmful for anything except public and private.

[mdparker]

@skyline131313 I've emailed you recently about moving this into review. Please get back to me when you're ready to move forward.

[rikkimax]

This will need to show benefit over inference of safety (which it currently does not).