Is @safe still a work-in-progress?

[Peter Alexander]

On Thursday, 30 August 2018 at 16:57:05 UTC, Maksim Fomin wrote:
> 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).

I think it is understood that any compile time checking must be 
conservative in the general case to be sound. The same is true 
for compile time type checking, which must reject type safe code 
that can only be determined type safe at runtime.

Adding runtime checks does sound reasonable, and D already does 
this for array bounds.