On 2/5/15 3:23 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 05, 2015 at 03:14:18PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/5/15 2:43 PM, H. S. Teoh via Digitalmars-d wrote:
The idea is that while we would like the compiler to mechanically
verify *everything*, in practice there are some things that the
compiler simply cannot verify. Since those remaining things require
human effort to verify and humans are prone to errors, we would like
to limit the scope of those things by confining them inside @trusted
functions, which, ideally, would be few in number and limited in
scope. Everything else should be relegated to @safe functions, where
we *require* completely automated verification by the compiler.
What's the difference between an internal scope and a separate
function scope? That is, a static internal function can simply be a
private module function and have the same effect.
I don't see how your proposal is more safe than mine, or that somehow
I can expect a @safe function never to have manually verified code
that it uses.
[...]
It's as Walter just said: @safe means the compiler has mechanically
verified it, @trusted means the compiler has *not* verified it but that
a human did (or so we hope). If you like, think of it as
@safe-compiler-verified vs. @safe-human-verified. By segregating the
two, you limit the scope of code that needs to be reviewed. Of course,
this is only of interest to the maintainer of the code, really, to the
user both sport a @safe API and there is no distinction.
I'll put out a strawman similar to my example response to Zach:
@trusted int[] tmalloc(size_t x) { ... }
@trusted void tfree(int[] x) { ... }
Now, let's say these are in some module you use, and your code is:
void foo() @safe
{
auto x = tmalloc(100);
tfree(x);
...
x[0] = 1;
}
foo is "mechanically verified", but it's not really, because tmalloc and
tfree are not. Now, you may just trust that tfree is fine, you may go
and verify what tfree does. But in either case, you still have the
problem that tfree(x) and the usage of x may be far away from each
other, and may even be written by different people at different times.
The compiler will still fail you in this regard, because it will not
complain.
Understand that I don't disagree with your proposal, I just think it can
be reduced to mine, and is unnecessarily complicated.
I think the *fundamental* problem with @trusted (currently) is that it
assumes all the code it covers was written simultaneously and is not
allowed to morph. This isn't the way code is written, it's massaged and
tweaked over long periods of time by different people.
In any case, it doesn't look like anything is going to change after all,
so this discussion has is just another of those what-could-have-beens
rather than what could be.
Don't give up so easily ;)
-Steve
