On 28-Jul-12 04:08, David Nadlinger wrote:
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).
No question here, @trusted should be usable in place of @safe
_transparently_.
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.
Finally proper granularity for trusted!
I'd say that SafeD is still unusable mostly because @trusted is too
blunt (your example from std.uuid).
The day writeln works for all safe types (with safe/trusted toString or
whatever) I'd call SafeD barely usable.
I believe it need not introduce another scope.
--
Dmitry Olshansky
