misplaced @trust?

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 05, 2015 at 02:11:32PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 2/5/15 1:54 PM, H. S. Teoh via Digitalmars-d wrote:
> 
> >However, I don't agree that the entire function can be marked @safe.
> >Otherwise, @safe code will now contain arbitrary @trusted blocks inside,
> >and so anybody can freely escape @safe restrictions just by putting
> >objectionable operations inside @trusted blocks. The function still
> >needs to be marked @trusted -- to draw attention for the need of
> >scrutiny -- *but* the function body is still confined under @safe
> >requirements, except that now the "escape hatch" of @trusted code blocks
> >are permitted as well.
> 
> Let's assume @trusted means @safe code can call it, but it may have
> @system-like functionality in it (however it happens).
> 
> Whether it's in an internal lambda/nested static function or not, the point
> is, @safe code can call @trusted code. To say that @safe makes some promises
> above/beyond @trusted is just incorrect.

No, @safe means the compiler can mechanically verify that it is safe,
under the assumption that any @trusted function called from @safe code
has been manually verified. @trusted means the compiler was not able to
mechanically verify the whole function, but it has been manually
verified to be safe.

If you allow @system variables in @safe code, then you're essentially
make @safe the same thing as @trusted, which means the compiler cannot
verify *anything*, so it's making the problem worse, as now you have to
manually verify *all* @safe code instead of just the @trusted portions.


> Now, if you're saying @trusted cannot be called via @safe, then I
> don't know what your plan is for @trusted :) If that's true, please
> explain.
[...]

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.

As it turns out, even within these @trusted functions, we humans could
use some help, therefore we'd like the compiler to help us verify as
much of these functions as it can for us, and then we can manually check
the remaining bits that cannot be mechanically verified. To this end,
your idea of tainting data is a valuable tool: by limiting @system-ness
to explicitly marked variables, we increase the scope of automatic
verification even inside @trusted functions, so that the compiler can
help us catch some things that we may have missed when we manually check
the code.

If we allow these @system variables inside @safe code, then we have
defeated the purpose of having @trusted functions in the first place,
because now the scope of functions that require manual inspection
expands to *all* @safe functions, which increases the maintainability
problem rather than reduce it.

Likewise, in the current implementation @trusted is a wholesale license
to perform arbitrary @system operations, which increases the difficulty
of manually verifying @trusted functions. (In fact, it's disastrous,
since you cannot guarantee that a code change in some remote function
won't change the trustworthiness of a verified @trusted function.)
Requiring potentially-unsafe data being explicitly marked @system allows
us to continue to impose @safe restrictions on everything else, thereby
reducing the scope of the remote-code-change problem to overtly marked
places where we can focus our scrutiny.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye