@trusted considered harmful

[Artur Skawina]

On 07/28/12 02:08, 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 with @trusted is that it is transitive.

@trusted should allow unsafe operations in the covered scope (right now -
the function), but disallow calling unsafe (@system) code. IOW a @safe
function should only be able to call a @safe or @trusted one, and the same
restriction should apply to @trusted functions. This way you can actually
audit the code - something which isn't typically possible right now, when
you have no control over what the "trusted" code might call.

There are two issues w/ such a change
1. Backward compatibility
2. Being able to override the restrictions (eg for debugging)

Both can be addressed by having a trust-me-harder mode, which can be
implemented as "@trusted @safe", ie functions marked with both attributes
behave just as @trusted code does right now.

Yes, @safe and @trusted do not need different name mangling.

The '@attribute {}' syntax is something that is needed, but should probably
wait for /proper/ attribute handling, which should also allow for a saner
'synchronized' etc.

'{}' not introducing a scope is not the most intuitive approach (yes, this
includes the currently existing cases too).

artur