On Saturday, 28 July 2012 at 00:08:30 UTC, David Nadlinger wrote:
@trusted in its current form needs to go. Its design is badly
broken, as it leaks implementation details and encourages
writing unsafe code.
The Problem
———————————
[...]
A Solution
——————————
Let me make something clear first: I am _not_ intending to
remove @trusted from the language. As a bridge between the
@safe and @system worlds, it is an integral part of SafeD. What
I'm proposing is:
1) Remove the distinction between @safe and @trusted at the
interface (ABI, API) level. This implies changing the name
mangling of @trusted to Nf, and consequently removing the
distinction in DMD altogether (at least in user-facing parts
like .stringof and error messages). In theory, this is a
breaking change, but as any code that doesn't treat them the
same is buggy anyway, it shouldn't be in practice. As for
std.traits.FunctionAttribute, we could either make trusted an
alias for safe, or just remove documentation for the former and
keep it around for some time (there is no way to deprecate an
enum member).
2) The first step is necessary, but mainly of cosmetic nature
(think `pure`, `pure2`). We still need to address for the
granularity and attribute inference problem. The obvious
solution is to add a "@trusted" declaration/block, which would
allow unsafe code in a certain region. Putting @trusted in the
function header would still be allowed for backwards
compatibility (but discouraged), and would have the same effect
as marking the function @safe and wrapping its whole body in a
@trusted block. It could e.g. look something like this (the @
prefix definitely looks weird, but I didn't want to introduce a
new keyword):
---
void foo(T)(T t) {
t.doSomething();
@trusted {
// Do something dirty.
}
t.doSomethingElse();
@trusted phobosFunctionWhichHasNotBeenMarkedSafeYet();
}
---
This is similar to other constructs we have today, for example
debug {}, which allows impure code. It can be debated whether a
block »argument« should introduce a new scope or not (like
static if). The latter currently seems much more attractive to
me, but I suppose it could be confusing for some.
In any case, while there is probably quite a bit of
bikeshedding to be done for 2), I don't think there is much
controversy about 1). So, let's try to get this done shortly
after the 2.060 release – as discussed above, it is very
unlikely that the change will break something, but the odds
still increase over time. Also, there is currently a Phobos
pull request [4] which will be influenced by the outcome of
this discussion.
I completely agree with the above. @trusted should be applied to
as small blocks of code as possible -- preferably to individual
statements -- to make it easier for the programmer to verify and
maintain the safety of the code.
Lars
