On Fri, 11 Apr 2014 08:37:59 -0400, Tommi <tommitiss...@hotmail.com> wrote:
On Friday, 11 April 2014 at 12:00:32 UTC, Steven Schveighoffer wrote:
On Fri, 11 Apr 2014 00:01:17 -0400, Tommi <tommitiss...@hotmail.com>
wrote:
On Friday, 11 April 2014 at 00:52:25 UTC, Steven Schveighoffer wrote:
If @safe is just a convention, then I don't see the point of having
it at all. If it can't be a guarantee, then it's pretty much another
tech buzzword with no teeth.
In order to have @safe be a guarantee of memory-safety, we need to
prevent @safe code from calling any @trusted code.
Or manually guarantee the safety of @trusted code.
I should be able to write an application with only @safe functions, and
trust that phobos has implemented @trusted functions properly.
I was talking about @safe in general sense, not only as it pertains to
phobos.
@trusted code needs to be severely scrutinized, since you are turning off
safety checks, no matter where the code is. My point was that if I want to
ONLY write @safe code, I should be able to without fear that the @trusted
functions in Phobos are susceptible to memory bugs.
The idea is that the number of functions that are @trusted is very small,
so we can be extra cautious and focused with them. Then the number of
@safe functions can be quite large and useful. Kind of like casts -- you
should really scrutinize and focus on casts to make sure nothing untoward
is happening, since the compiler is deferring to you.
One thing that kind of sucks about this, is that @safe vs. @trusted is a
large bag of safety checks. If all you want is to disable array bounds
checking, for maybe one or two array indexes in a large function, it's a
large price to pay to mark the entire function @trusted. Inner functions
help with this a bit, but maybe one should be able to mark an expression
as @trusted inside a @safe function. Give the developer a scalpel instead
of a saws-all.
-Steve
