[OffTopic] A vulnerability postmortem on Network Security Services

[jmh530]

On Wednesday, 8 December 2021 at 15:46:31 UTC, Steven 
Schveighoffer wrote:
> [snip]
>
> I proposed [during the 
> discussion](https://forum.dlang.org/post/r6kvm4$1vq5$1@digitalmars.com) that you can assume `extern(C)` functions are `@safe` as long as they are mangled differently. I think that would both solve the problems people had, and allow `extern(C)` to be safe by default.
>
> Walter seemingly ignored it, but silently [hated 
> it](https://forum.dlang.org/post/ra7958$2r8v$1@digitalmars.com), so I don't see that happening.
>
> -Steve

I think Walter (and likely Atila too) might come down on avoiding 
special casing as an important design goal.

To me, the best way to ensure that is to moving @safe from a 
black list to an white list. That is, @safe is currently 
structured so that you cannot do certain things. If instead it is 
structured so that only certain things are allowed, then 
something like having the body of the function available could be 
on that list. There would be no more special casing and it would 
only break code to the extent that the white list and black list 
do not match up (which might be considerable, who knows)