Le 28/07/2012 16:02, Andrei Alexandrescu a écrit :
This is sensible, but I fail to figure how it adds value over marking
functions as @trusted. Sure, it's finer-grained, but it's also less
structured.
Let me explain you the a problem I faced this week which illustrate
pefectly the problem.
I have a function which is @system. The function caller have to ensure
the parameters are correct. If it does, then the function is @trusted as
of current semantic.
Let's call that function foo .
I have a second function, bar, which is a template function. This bar
function uses reflection on an object and also use foo. The usage of foo
is checked, so bar is supposed to be @trusted if all functions called by
reflection are @safe or @trusted.
In pseudo code :
void foo(arguments) @system;
void bar(T)(T t) {
// Reflect T and perform operations, sometime calling reflected
methods.
// call foo with checked arguments.
}
Now, as multiple reflected method can be called, it is really hard to
check if bar is @trusted or @safe .
At the end, I ended up not marking the code @trusted which make it
@system, even if it is safe in most cases. Simply because it is too
difficult to know in which case it is @trusted.
With the proposal, code becomes :
void foo(arguments) @system;
void bar(T)(T t) {
// Reflect T and perform operations, sometime calling reflected
methods.
@trusted {
// call foo with checked arguments.
}
}
The problem is very real and the solution elegant. Any code analyzer
will be able to look for @trusted block anyway, as it is certainly a
concern to do more code review on @trusted blocks.
