misplaced @trust?

[Zach the Mystic via Digitalmars-d]

On Thursday, 5 February 2015 at 19:19:51 UTC, H. S. Teoh wrote:
> - @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

This is another interesting addition to the original proposal. My 
initial response is that if I were building the system from the 
ground up, I might not understand why a function needs to be 
redundantly marked @trusted, since the unsafe data is already 
casted(@safe) inside the function. Yet two factors start to sway 
me in favor of what you're saying, despite my initial doubt:

1. Memory safety is serious business. Forcing people to mark 
potentially unsafe functions @trusted instead of @safe, while (as 
Steven Schveighoffer pointed out) actually meaning nothing to the 
caller, will allow maintainers to more easily detect possible 
problems. In other words, it's a redundancy, but it's a GOOD 
redundancy because of how serious safety issues are. I don't know 
how strong this argument is, but it seems sound and I'm willing 
to go with it, barring good reasons not to.

2. It's already there in the language. This heavily reduces the 
"switching costs". While not a great argument in itself, to my 
mind anyway (#pleasebreakourcode ;-), it does seem more likely to 
be accepted by people who fear the change.