On 06/05/2014 08:35 PM, Steven Schveighoffer wrote:
On Thu, 05 Jun 2014 14:30:49 -0400, Timon Gehr <[email protected]> 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:"
