misplaced @trust?

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 05, 2015 at 06:56:02PM +0000, Zach the Mystic via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 18:21:40 UTC, Steven Schveighoffer wrote:
> >On 2/5/15 1:12 PM, Zach the Mystic wrote:
> >
> >>
> >>Hey I like the creativity you're showing. Just to give people a
> >>concrete idea, you might show some sample code and illustrate how
> >>things work. It sure helps when I'm trying to think about things.
> >
> >So for example:
> >
> >@safe int *foo()
> >{
> >   int *x;
> >   int *y;
> >   int z;
> >   x = new int; // ok
> >   //y = &z; // not OK
> >   @trusted y = &z; // OK, but now y is marked as @trusted
> >   // return y; // not OK, cannot return @trusted pointer in @safe
> >function
> >   return cast(@safe)y; // ok, we are overriding the compiler.
> >   // and of course return x; would be ok
> >}
> >
> >-Steve
> 
> `cast(@safe)`...interesting. It's the most fine-tuned way of adding
> safety, whereas @trusting a whole function is the most blunt way.
> 
> I've been hatching a scheme for reference safety in my head which would
> automatically track `@trusted y = &z;` above, marking `y` with
> "scopedepth(1)", which would be unreturnable in @safe code.
> 
> I can anticipate the objection that giving people too much power will
> encourage them to abuse it... but then again, if that were true, who
> let them mark the whole function `@trusted` to begin with? Your
> proposal really pinpoints the actual code which needs to be worked on.
> 
> You're basically moving the unit of safety from the *function* to the
> *pointer*, which makes sense to me, since only a pointer can really be
> unsafe.

I mostly like this idea, except that foo() should not be marked @safe.
It should be marked @trusted because it still needs review, but the
meaning of @trusted should be changed so that it still enforces
@safe-ty, except that now @trusted variables are permitted. Or rather, I
would call them @system variables -- they *cannot* be trusted, and must
be manually verified.

@safe code should not allow any @system variables or any cast(@safe)
operations, period. Otherwise, anybody can wrap unsafe operations inside
their @safe function and still clothe it with the sheep's clothing of
@safe, and @safe becomes a meaningless annotation.

In short, my proposal is:

- @safe should continue being @safe -- no (potentially) unsafe
  operations are allowed, period.
  
  Rationale: allowing @system variables in @safe code makes the function
  non-verifiable mechanically. This completely breaks the whole point of
  @safe.

- Change the meaning of @trusted (as applied to a function) to require
  @safe inside the function body, but in addition permit @system
  variables and cast(@safe).
  
  Rationale: the function cannot be verified mechanically to be safe,
  therefore it cannot be marked @safe. It must be marked @trusted to
  draw attention to the fact that manual review is required. However,
  this does not constitute license to perform arbitrary @system
  operations. Instead, any @system code/variable inside the @trusted
  function must be explicitly marked as such, to indicate that these
  items require special attention during review. Everything else must
  still conform to @safe requirements.

- Introduce @system variables for holding tainted values that the
  compiler cannot guarantee the safety of, as well as cast(@safe), as
  described in Steven's post. These constructs are only permitted inside
  @trusted functions. They are prohibited in @safe code, and are no-ops
  in @system code.

  Rationale: to reduce the maintainability problem, @trusted functions
  should not allow @system code by default. Rather, the scope of @system
  code/data inside a @trusted function should be restricted by requiring
  explicit marking. The compiler then helps the verification process by
  ensuring that anything not explicitly marked is still @safe.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum