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.
