misplaced @trust?

[Steven Schveighoffer via Digitalmars-d]

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