On Thursday, 2 December 2021 at 17:11:09 UTC, Paul Backus wrote:
> On Thursday, 2 December 2021 at 16:44:42 UTC, Tejas wrote:
> Wish the @safe by default DIP had passed :(
Any hope of reviving it and merging into master??
Only if someone can (a) come up with a better solution for handling extern(C) functions, and (b) convince Walter to accept it.
I think a more likely path forward is to allow the programmer to specify default attributes in such a way that they can still be overriden by inference. For example:
// Make @safe the default for the rest of this scope
default(@safe):
// defaults to @safe
int foo(int n) { return n; }
// error: can't cast integer to pointer in a @safe function
int* bar(int n) { return cast(int*) n; }
// ok: inferred as @system (because of `auto`)
auto baz(int n) { return cast(int*) n; }
This is the same idea as Adam D. Ruppe's attribute proposal, but with new syntax to avoid potential breakage to existing code.
As Adam explains in his article, we cannot do this by simply applying the @safe attribute globally, because doing so will override the compiler's attribute inference, and cause compilation of functions like baz to fail. (Example: https://run.dlang.io/is/s9iuKq)
Hmm... not a fan of that solution
Still feel marking extern (C) stuff as @trusted is better.
Introducing a new feature for such a fundamental, yet obvious thing seems overkill, IMHO. Forcing not @safe stuff to be annotated seems better to me.
Maybe we should relent and just let Walter mark the extern stuff as @safe even though it's not... ideal??
Or disallow marking any extern function as @safe, only @trusted? That's again introducing unnecessary complexity though :(
Gah, I say let him have his way, it's not worth adding a new feature/syntax for, but not something we should just let sit on ice either, else "it will break old code" will rear it's ugly head again
Permalink
Reply
