On 2/5/15 3:54 PM, Walter Bright wrote:
On 2/5/2015 12:25 PM, Steven Schveighoffer wrote:
On 2/5/15 3:13 PM, Walter Bright wrote:
So the question is, what does @trusted actually buy you, since the
compiler can't check it?
It serves as notice that "This function merits special attention during
code review to check that it has a safe interface and that its
implementation is correct."
That also applies to @safe functions since they can call @trusted
functions.
No - the @trusted function is reviewed to ensure it has a safe
interface. Then there is no need to review for safety anyone that calls
it. It's the whole point.
So you're saying that @safe is mechanically verified as long as @trusted
functions are manually reviewed. It's that manually reviewed part that I
think we have an issue with. And there is definitely a feel of "I can
use trusted because I know I will only call it this way" without
considering future possible calls.
I fully expect we can devise rules to make sure @trusted memory details
do not leak out of the functions in an unsafe way (and have a much
better, @safer code base). But it would be nice if the compiler helped
enforce them.
In essense, @trusted buys you headaches. I think we should try to
lessen them.
An aspect of a well-designed encapsulation is the number of @trusted
interfaces is minimized. If you find an abstraction that has @trusted
sprinkled liberally through it, it's an indicator of a failed abstraction.
I think you just made this up :)
But I agree that @trusted should be used sparingly not liberally. The
problem is that when faced with such a huge function that calls one
non-@safe one, marking the whole thing as @trusted disables all the
mechanical verification for everything.
There has to be a better way.
-Steve
