On Fri, May 22, 2020 at 12:03:00PM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: [...] > Or worse, it's not discovered and then D's already shaky reputation > for @safe code is destroyed when a hacker exploits the memory > corruption in fully-marked @safe code. [...]
TBH, this whole fiasco just confirms my initial skepticism about @safe. The concept of mechanical verifiability is cool, I'm on board with that. But the execution of it in @safe up to before this DIP already left a lot to be desired (the beginning of which is the fact that @safe is based on a blacklist rather than a whitelist, but let's not go there now). Now with this DIP, it's basically another nail in the @safe coffin. Essentially what it means is that @safe is a nice tool to have for casual use, but don't depend on it for real-world, mission critical use, because it doesn't have the strong guarantees you might imagine it has. It promises a lot in bold letters, but the fine print contains a lot of disclaimers. Which means, in my case, it's not worth bothering with. The amount of effort required to make code 100% @safe is just not worth the leaky "guarantees" it brings. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
