[OffTopic] A vulnerability postmortem on Network Security Services

[Tejas]

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:
>
> ```d
> // 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][1], 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)
>
> [1]: 
> https://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_13.html

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