Is @safe still a work-in-progress?

[Maksim Fomin]

On Friday, 17 August 2018 at 07:19:25 UTC, Peter Alexander wrote:
>
> My question is: what is the status of @safe? I am quite 
> surprised to see such a simple case fail. Is @safe believed to 
> be fully implemented (modulo bugs) and this is just an 
> unfortunate corner case, or is it known work-in-progress?

Years ago (2012-2013 
https://forum.dlang.org/post/xibbzslaunogifsomapl@forum.dlang.org) I was arguing that @safe is crippled: 1) there is high probability that some loopholes are missing (several of them were posted to bugzilla and still not fixed since then) 2) fixing loopholes will make using @safe inconvenient.

My point is somewhat different from expressed already here by 
Jonathan. He speaks about whitelisting/blacklisting and that the 
former model will always contain loopholes. In my view, the 
reason is that memory safety in (essentially good old C) memory 
model depends on runtime memory type which is unrelated to static 
type. Taking random variable - it can be allocated on stack, 
heap, GC-heap, thread-local and there is no way at CT to 
determine this in general case. In other words, static type rules 
is bad approach to determine memory safety. It can be used to 
detect some obvious bugs, but does not work across compilation 
boundaries. The better approach in my view is to insert runtime 
code which performs some tests (at least this how C# works).