DIP1028 - Rationale for accepting as is

[H. S. Teoh]

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.