misplaced @trust?

[H. S. Teoh via Digitalmars-d]

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.

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.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney