@safe inference fundamentally broken

[Timon Gehr via Digitalmars-d]

On 06/05/2014 08:35 PM, Steven Schveighoffer wrote:
> On Thu, 05 Jun 2014 14:30:49 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> The fundamental issue seems to lie in methodology and it is that @safe
>> is approximated by the DMD implementation from the wrong side. Instead
>> of gradually banning usage of more and more constructs in @safe, the
>> implementation should have started out with not allowing any
>> constructs in @safe code and then should have gradually allowed more
>> and more manually verified to be memory safe constructs.
>
> I think I was one of those who argued to do it gradually. I was wrong.

I don't understand. Both strategies are gradual.

> When one is manually marking @safe things, it's not as bad as when the
> compiler is automatically marking them. But in either case, @safe
> doesn't really mean safe, so it is pretty much useless.
>
> -Steve

Actually there are two conflicting definitions of @safe in the 
documentation. One says that @safe means memory safe and the other says 
that @safe means what DMD does:

dlang.org/function.html

"Function Safety

Safe functions are functions that are statically checked to exhibit no 
possibility of undefined behavior. Undefined behavior is often used as a 
vector for malicious attacks.

Safe Functions

Safe functions are marked with the @safe attribute.

The following operations are not allowed in safe functions:

[ too short list ]"

It then goes on to note:

"Note: The verifiable safety of functions may be compromised by bugs in 
the compiler and specification. Please report all such errors so they 
can be corrected."

This is simply the wrong way to go about it.

The documentation should instead say:

"The following operations are _allowed_ in safe functions:"